Announcement

Collapse
No announcement yet.

[CLOSED] [#2539] Is compiling of "abstract" member buggy?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    [CLOSED] [#2539] Is compiling of "abstract" member buggy?

    As you can see "this.Name" is never declared in JS. It looks like bridge compiler cannot handle overrides for now.
    So virtual members can have different names in generated JS, but maybe it was made intentionally and we should care about Name attribute in both classes.

    public abstract class Base
        {
            protected internal abstract string Name { get; set; }
    
            public string Test()
            {
                   return this.Name + this.Name;
            }
        }
    
        public class Model : Base
        {
            #region Fields
            private readonly Observable<string> _name = new Observable<string>("Test1");
            #endregion
    
            #region Properties
            [Name("name")]
            protected internal override string Name
            {
                get { return this._name.Value; }
                set { this._name.Value = value; }
            }
            #endregion
        }
     Bridge.define("BridgeApp.Base", {
            test: function () {
                   return System.String.concat(this.Name, this.Name);
            }
        });
    
    Bridge.define("BridgeApp.Model", {
            inherits: [BridgeApp.Base],
            _name: null,
            config: {
                properties: {
                name: {
                        get: function () {
                            return this._name();
                        },
                        set: function (value) {
                            this._name(value);
                        }
                    }
                },
                init: function () {
                    this._name = ko.observable("Test1");
                }
            }
        });

    #2
    Just so we're all using the same code, please share Deck.NET sample demonstrating your scenario. The code you provided does not compile.

    I see you're using Bridge 16, and Deck is currently on 15.7, but we'll test in both releases.

    Comment


      #3
      It is just sample to demonstrate idea... of course it will not compile without Observable class defined.
      I replaced it to to string... In any case main idea is how bridge generates names of overridden properties (and most likely other members).

      https://deck.net/04c72f0d7e1e3838e59bba07e22b07d4

      As I said in original post "this.Name" (or getName in 15.7) is not declared in JS object containing this properties.
      So Name attribute is applied to overridden property but not to its abstract parent.
      And my question was: is it bug or feature?

      Comment


        #4
        A few tips that will help speed up the process when sharing your Deck samples in the future:

        1. Remove all code that is not directly related to the problem and serves no purpose in demonstrating the problem. For example, the #region's scattered throughout your samples.
        2. Demonstrate an expected output. There is usually some way to highlight the issue by outputting something to the Console. Use Console.WriteLine(...) to output something relevant to the problem, with a comment above the Console.WriteLine call noting the expected result.

        I revised your sample to simplify and write something to the Console.

        Requires Bridge 16+:
        https://deck.net/26ef469b11141f3f53bc37604c71dbf9

        public class Program
        {
            public static void Main()
            {
                var m = new Model { Name = "Hello" };
        
                // HelloHello
                Console.WriteLine(m.Test());
            }
        }
        
        public abstract class Base
        {
           protected internal abstract string Name { get; set; }
        
           public string Test()
           {
                return this.Name + this.Name;
           }
        }
        
        public class Model : Base
        {
            [Name("name")]
            protected internal override string Name { get; set; }
        }
        We reproduced the issue and are reviewing, although, at the moment we're not sure supporting this scenario is possible.
        Last edited by geoffrey.mcgill; 2017-10-13 @ 06:08 PM.

        Comment


          #5
          I have created my sample from real app code.
          I have removed a lot of code already, obfuscated names and so on... But of course something not necessary can be still there.

          I did not call Test because it will obviously fail. I just highlighted in bold what is compiled wrong (if it is bug).

          Another reason to display a bit more code than enough to reproduce error is to show uses case of specific bridge features.
          Otherwise you can theoretically say: "why do you need that?"

          In any case some code style rules obvious for you are not obvious for me.. sorry guys ))

          Regarding the issue itself... I understand both ideas:
          1) control names manually.
          2) control overridden members automatically, considering whole hierarchy.

          Of course #1 is simpler and it is what you can prefer to support and it can be enough for developers... just let us know your final decision...
          From my point of view if we are talking about full support of C# language features then changing of name of virtual member should spread to whole hierarchy: all parent and derived classes as well as all implicit or explicit interface implementations.
          But it is just theory... From practical side I can workaround it without custom names. But maybe somebody will experience more troubles regarding that.
          So I assumed it could be good to inform Bridge team.

          Comment


            #6
            We have created Issue #2539 to track this scenario.

            Comment


              #7
              Our position is that you are purposely violating the contract between the base class and implementation class. Under those conditions, we cannot tell if you're doing this on purpose or not. It might be a deliberate action on the part of the developer.

              The Attributes enable great flexibility to customize the JavaScript generated by Bridge, but those overrides might cause unintended consequences in your application runtime code.

              There was a suggestion by Vladimir in #2539 to throw an Exception if this scenario was encountered. We have discussed the proposal, but we're concerned this would just trigger other intended consequences.

              As a general rule, if you're manually (explicitly) overriding entity names, then it's up to the developer to manage.

              For now, we cannot provide a solution.

              Comment


                #8
                OK
                You cannot provide solution...

                But that means we do not have the way to specify custom name for any virtual member.
                So for some members we can do that.. but if member becomes virtual we cannot do that.

                Sounds like valuable limitation... Not critical.. most likely it can be workaround-ed.
                But in such cases it is reasonable to publish all current limitations on main page of GitHub repository.
                It is much better to think how to solve it 'before' than 'after'.

                Comment

                Working...
                X