Loading ...
Sorry, an error occurred while loading the content.

Re: [eiffel_software] Change to SPECIAL in 6.6

Expand Messages
  • Peter Gummer
    ... Hmm, nice plan, but that isn t what happened. In order to use Gobo in 6.6, I had to replace references to gobo.ecf with this:
    Message 1 of 20 , Aug 9, 2010
    View Source
    • 0 Attachment
      Emmanuel Stapf [ES] wrote:

      >> he issue is not that from one release to the next but because we
      >> are actually providing two sets of libraries and the current
      >> default libraries were introduced 2 releases ago although not as
      >> default. In 6.4 we introduced two modes and the release notes were
      >> explicit about the changes recommending people to use both modes to
      >> ensure their code works equally well in both. As stated in the 6.4
      >> release notes:
      >
      > <<
      > Users are encouraged to compile with the experimental libraries in
      > order to prepare their code for the future when today's experimental
      > libraries will become the de facto libraries. It is possible to
      > adjust code so that a single version compiles against both sets of
      > libraries.
      >>>

      Hmm, nice plan, but that isn't what happened. In order to use Gobo in
      6.6, I had to replace references to "gobo.ecf" with this:

      <library name="gobo_kernel" location="$ISE_LIBRARY\library\gobo
      \gobo_kernel.ecf"/>
      <library name="gobo_lexical" location="$ISE_LIBRARY\library\gobo
      \gobo_lexical.ecf"/>
      <library name="gobo_parse" location="$ISE_LIBRARY\library\gobo
      \gobo_parse.ecf"/>
      <library name="gobo_structure" location="$ISE_LIBRARY\library\gobo
      \gobo_structure.ecf"/>
      <library name="gobo_utility" location="$ISE_LIBRARY\library\gobo
      \gobo_utility.ecf"/>
      <library name="gobo_xml" location="$ISE_LIBRARY\library\gobo
      \gobo_xml.ecf"/>

      Presumably the same change would be necessary in 6.4 experimental mode
      (although I've never attempted it), since that was where "gobo.ecf"
      was originally removed. But this change does not compile in 6.4
      standard mode, because "gobo_kernel.ecf" refers to a cluster that does
      not exist in 6.4's standard gobo libraries. Two separate ECFs are
      required.

      - Peter Gummer
    • Peter Gummer
      ... That s true, unfortunately. We have a bit of C# code that uses SPECIAL, which was written by someone who has never programmed in Eiffel:
      Message 2 of 20 , Aug 9, 2010
      View Source
      • 0 Attachment
        rfo@... wrote:

        > Using obsolete is in keeping with the notion that Eiffel at least
        > tries
        > to support software engineering. Assuming that only a few expert
        > users
        > might be impacted, and that by implication, they should know better,
        > is
        > contrary to that spirit.

        That's true, unfortunately. We have a bit of C# code that uses
        SPECIAL, which was written by someone who has never programmed in
        Eiffel:

        EiffelStructures.list.Impl.ARRAYED_LIST_REFERENCE
        castList = currentObject.code_list() as
        EiffelStructures.list.Impl.ARRAYED_LIST_REFERENCE;
        EiffelKernel.dotnet.Impl.SPECIAL_REFERENCE sList =
        (EiffelKernel.dotnet.Impl.SPECIAL_REFERENCE)(castList.area());

        Yes, that's right, C# .NET code doing all sorts of horrible things
        with the innards of Eiffel objects, committing all sorts of sins:
        accessing the implementation rather than the interface, using the
        'area' attribute of a STRING, casting to SPECIAL. Scary, isn't it?

        I've recently rewritten this code to be well behaved. I can only
        assume that the original programmer discovered these secret attributes
        and types in the Visual Studio debugger and, being ignorant of Eiffel,
        decided that this is how things should be done. (The programmer was
        able to slip this nasty code past the C# compiler's type checker
        because, for some reason I do not understand, all features inside an
        Eiffel .NET assembly are public.)

        - Peter Gummer
      • rfo@amalasoft.com
        Hi Manu The experimental library mechanism is a good thing, but please recall the flip-flop that occurred on that front when void-safety was changed from
        Message 3 of 20 , Aug 10, 2010
        View Source
        • 0 Attachment
          Hi Manu

          The experimental library mechanism is a good thing, but please recall
          the flip-flop that occurred on that front when void-safety was changed
          from default back to experimental. It's not perfect, is it?

          The code in question (from a former ISE partner by the way), called
          TO_SPECIAL.make_empty_area, which in turn calls SPECIAL.make_empty, not
          make, and so did not encounter the compilation failure you mention.
          Thus, it was not caught in the tests you must have run to verify that
          make would indeed fail. The code in question, as I stated did in fact
          compile and did indeed crash. The code was unchanged from 6.5 to 6.6.
          It executed correctly in 6.5.

          I would recommend, once again, thst instead of requiring build and test
          cycles for customer code just to find the presence of a KNOWN breaking
          change, the the obsolete mechanism also be used to highlight this in the
          default code. I really don't see the problem with doing this and I hope
          the benefit is obvious. If any of us wants to hide those messages, you
          already proide a mechanism for doing so.

          The implication that I am either not one of those "advanced users" that
          uses SPECIAL, or just not paying attention does not address the issue,
          even if it were true. I am trying to offer a way to make the process
          better.

          The steps you have taken are positive and helpful (removing make,
          providing default and experimental libraries) but more can be done to
          ensure that attempts to use Eiffel in a production environment are less
          painful and less risky. It's hard enough to convince today's
          programmers to use Eiffel. Having episodes like this one, though in
          absolute terms a small error, only make it harder.
          Thanks
          R

          ==================================================
          Roger F. Osmond


          > -------- Original Message --------
          > Subject: RE: [eiffel_software] Change to SPECIAL in 6.6
          > From: "Emmanuel Stapf [ES]" <manus@...>
          > Date: Mon, August 09, 2010 7:49 pm
          > To: <eiffel_software@yahoogroups.com>
          >
          >
          > > The code in question compiled without warning in 6.5 and worked
          > > correctly. In 6.6, it compiled without warning and crashed. How that
          >
          > In theory, there is no way it could have compiled out of the box in 6.6 since `make' was removed and this would cause a compilation error. Only if you have already started to perform some modification so that it worked with both modes then you end up with code that compile but that might not work if improperly used for void-safety. Are you sure it is not the later?
          >
          > > Now that new versions are appearing regularly (a good thing), it seems
          > > that there should be a tighter process for breaking changes. It may be
          > > a lot to ask, but it's important. The release planning has evidently
          > > become quite a bit more solid, and so it should be not too difficult to
          > > anticipate by one release what might be breaking in the next. That can
          >
          > The issue is not that from one release to the next but because we are actually providing two sets of libraries and the current default libraries were introduced 2 releases ago although not as default. In 6.4 we introduced two modes and the release notes were explicit about the changes recommending people to use both modes to ensure their code works equally well in both. As stated in the 6.4 release notes:
          >
          > <<
          > Users are encouraged to compile with the experimental libraries in order to prepare their code for the future when today's experimental libraries will become the de facto libraries. It is possible to adjust code so that a single version compiles against both sets of libraries.
          > >>
          >
          > Maybe we did not emphasize this enough and clearly we need to do better in the future.
          >
          > Thanks for your comments,
          > Manu
        • Thomas Beale
          I for one would not want to criticise Manu and the team too much for not getting everything right in this game. It is tough, and consider the logistics - I
          Message 4 of 20 , Aug 10, 2010
          View Source
          • 0 Attachment
            I for one would not want to criticise Manu and the team too much for not
            getting everything right in this game. It is tough, and consider the
            logistics - I don't know how many platforms (remembering that 'platform'
            these days is just one variant of some platform x 32/64 bit etc) are
            currently supported, plus installers, online documentation and so on -
            not to mention thinking carefully about what might break cecil bindings
            and other special code. So for the 98% of the effort that has the right
            result, I can only say well done. We support much smaller tools on less
            platforms, with less quality (according to resources) and it is hard work.

            That said, I think Roger's argument is more or less correct on two
            points: 'obsolete' should be used as originally designed, even if it is
            true that some/many/most people ignore it. If they/we do, they/we can't
            say they/we were not warned. Secondly, I would not make any assumptions
            about who does things with classes like SPECIAL. Although I personally
            don't do much with it, I have been using INTERNAL and other
            round-the-back mechanisms nearly from day one to implement generic
            persistence mechanisms and so on, even though I had no pedagogic or
            other special interest in such classes - like many others, we use
            'special' classes/features just to solve some problem.

            Peter Gummer has pointed out the kind of things that have bugged us from
            time to time (e.g. Gobo ecf problems), which are not major, but
            nevertheless annoying to hit unexpectedly. I don't see any of these
            problems as really terrible, but it would be nice to think that between
            ES's dedicated work and some community feedback (= grumbling ;-) we are
            getting towards a beautiful technology delivered within a very clean
            process.

            - thomas beale

            On 10/08/2010 12:46, rfo@... wrote:
            >
            >
            > Hi Manu
            >
            > The experimental library mechanism is a good thing, but please recall
            > the flip-flop that occurred on that front when void-safety was changed
            > from default back to experimental. It's not perfect, is it?
            >
            > The code in question (from a former ISE partner by the way), called
            > TO_SPECIAL.make_empty_area, which in turn calls SPECIAL.make_empty, not
            > make, and so did not encounter the compilation failure you mention.
            > Thus, it was not caught in the tests you must have run to verify that
            > make would indeed fail. The code in question, as I stated did in fact
            > compile and did indeed crash. The code was unchanged from 6.5 to 6.6.
            > It executed correctly in 6.5.
            >
            > I would recommend, once again, thst instead of requiring build and test
            > cycles for customer code just to find the presence of a KNOWN breaking
            > change, the the obsolete mechanism also be used to highlight this in the
            > default code. I really don't see the problem with doing this and I hope
            > the benefit is obvious. If any of us wants to hide those messages, you
            > already proide a mechanism for doing so.
            >
            > The implication that I am either not one of those "advanced users" that
            > uses SPECIAL, or just not paying attention does not address the issue,
            > even if it were true. I am trying to offer a way to make the process
            > better.
            >
            > The steps you have taken are positive and helpful (removing make,
            > providing default and experimental libraries) but more can be done to
            > ensure that attempts to use Eiffel in a production environment are less
            > painful and less risky. It's hard enough to convince today's
            > programmers to use Eiffel. Having episodes like this one, though in
            > absolute terms a small error, only make it harder.
            > Thanks
            > R
            >
            > ==================================================
            > Roger F. Osmond
            >
          • Emmanuel Stapf [ES]
            ... This is strange because `TO_SPECIAL.make_empty_area does not exist in the compatible mode in 6.6 (nor does it exist in 6.5 default mode), so therefore
            Message 5 of 20 , Aug 10, 2010
            View Source
            • 0 Attachment
              > The code in question (from a former ISE partner by the way), called
              > TO_SPECIAL.make_empty_area, which in turn calls SPECIAL.make_empty, not
              > make, and so did not encounter the compilation failure you mention.

              This is strange because `TO_SPECIAL.make_empty_area' does not exist in the compatible mode in 6.6 (nor does it exist in 6.5 default mode), so therefore your code was already modified. Since this is not your code, it is hard to tell why it is not working properly. If you want to have code that compiles under both mode, you should be using the `make_filled' variants in SPECIAL and TO_SPECIAL.

              > compile and did indeed crash. The code was unchanged from 6.5 to 6.6.
              > It executed correctly in 6.5.

              Are you sure it compiled in 6.5 default mode as the above routine did not exist at the time.

              In the meantime, we will put `make' obsolete in the compatible mode so that it is more obvious.

              Regards,
              Manu
            • rfo@amalasoft.com
              Hi Manu! I ll take a crack at using make_filled_area, but I have it working now with make_empty already. The code was using count when it should have been
              Message 6 of 20 , Aug 10, 2010
              View Source
              • 0 Attachment
                Hi Manu!

                I'll take a crack at using make_filled_area, but I have it working now
                with make_empty already. The code was using "count" when it should have
                been using "capacity". In the olden days, and in 6.5, the
                _implementation_ of make_empty_area ensured that "count" was equal to
                the size argument given (ARRAY-like). The new postcondition ensures
                that capacity=n and that count=0, as one might expect. Everything looks
                as it should. The problem is that the implementation of SPECIAL changed
                and with it the behavior. As clients of any library class, we should
                expect implementation changes, but we should not have behavior changes
                without a warning mechanism of some kind, and that is core of the point
                I'm trying to make.
                The reality of the code in question (the regular expression code that
                is), is such that I might just replace most or all of it and bring it
                all into the current era.
                Thanks

                R

                ==================================================
                Roger F. Osmond


                > -------- Original Message --------
                > Subject: RE: [eiffel_software] Change to SPECIAL in 6.6
                > From: "Emmanuel Stapf [ES]" <manus@...>
                > Date: Tue, August 10, 2010 12:18 pm
                > To: <eiffel_software@yahoogroups.com>
                >
                >
                > > The code in question (from a former ISE partner by the way), called
                > > TO_SPECIAL.make_empty_area, which in turn calls SPECIAL.make_empty, not
                > > make, and so did not encounter the compilation failure you mention.
                >
                > This is strange because `TO_SPECIAL.make_empty_area' does not exist in the compatible mode in 6.6 (nor does it exist in 6.5 default mode), so therefore your code was already modified. Since this is not your code, it is hard to tell why it is not working properly. If you want to have code that compiles under both mode, you should be using the `make_filled' variants in SPECIAL and TO_SPECIAL.
                >
                > > compile and did indeed crash. The code was unchanged from 6.5 to 6.6.
                > > It executed correctly in 6.5.
                >
                > Are you sure it compiled in 6.5 default mode as the above routine did not exist at the time.
                >
                > In the meantime, we will put `make' obsolete in the compatible mode so that it is more obvious.
                >
                > Regards,
                > Manu
              • Emmanuel Stapf [ES]
                ... Wouldn t it be simpler to fix the broken 6.4 gobo_kernel.ecf in your own delivery of EiffelStudio? This was a specific issue on Windows for those who
                Message 7 of 20 , Aug 10, 2010
                View Source
                • 0 Attachment
                  > Presumably the same change would be necessary in 6.4 experimental mode
                  > (although I've never attempted it), since that was where "gobo.ecf"
                  > was originally removed. But this change does not compile in 6.4
                  > standard mode, because "gobo_kernel.ecf" refers to a cluster that does
                  > not exist in 6.4's standard gobo libraries. Two separate ECFs are
                  > required.

                  Wouldn't it be simpler to fix the broken 6.4 gobo_kernel.ecf in your own delivery
                  of EiffelStudio? This was a specific issue on Windows for those who installed
                  EiffelStudio 6.4 via the Windows Installer (which does not create empty directory
                  unless explicitely specified). The other solution would be to upgrade to 6.5.

                  Regards,
                  Manu
                • Emmanuel Stapf [ES]
                  ... Eiffel calls in .NET are always done via the interfaces generated by the compiler and in an interface everything is public. Regards, Manu
                  Message 8 of 20 , Aug 10, 2010
                  View Source
                  • 0 Attachment
                    > because, for some reason I do not understand, all features inside an
                    > Eiffel .NET assembly are public.)

                    Eiffel calls in .NET are always done via the interfaces generated by the compiler
                    and in an interface everything is public.

                    Regards,
                    Manu
                  • Emmanuel Stapf [ES]
                    ... Don t you mean the way around? ... In 6.5 `make_empty_area does not exist, you only had `make_area which has this guarantee. The `make_empty_area is
                    Message 9 of 20 , Aug 10, 2010
                    View Source
                    • 0 Attachment
                      > I'll take a crack at using make_filled_area, but I have it working now
                      > with make_empty already. The code was using "count" when it should have
                      > been using "capacity".

                      Don't you mean the way around?

                      > In the olden days, and in 6.5, the
                      > _implementation_ of make_empty_area ensured that "count" was equal to
                      > the size argument given (ARRAY-like).

                      In 6.5 `make_empty_area' does not exist, you only had `make_area' which has this guarantee. The `make_empty_area' is only present in the experimental version of 6.5 and in the default mode of 6.6.

                      > as it should. The problem is that the implementation of SPECIAL changed
                      > and with it the behavior.

                      But only between the modes, not between releases.

                      > As clients of any library class, we should
                      > expect implementation changes, but we should not have behavior changes

                      I believe that in your case something else might have occurred. I'd be happy to continue this offline with you to find out exactly what.

                      Regards,
                      Manu
                    • Peter Gummer
                      ... Yes, in an interface everything is always public. That doesn t solve the mystery, however. Why are all of the secret features of our Eiffel classes
                      Message 10 of 20 , Aug 10, 2010
                      View Source
                      • 0 Attachment
                        Emmanuel Stapf [ES] wrote:

                        >> because, for some reason I do not understand, all features inside an
                        >> Eiffel .NET assembly are public.)
                        >
                        > Eiffel calls in .NET are always done via the interfaces generated by
                        > the compiler
                        > and in an interface everything is public.

                        Yes, in an interface everything is always public.

                        That doesn't solve the mystery, however. Why are all of the secret
                        features of our Eiffel classes included in the public .NET interface?
                        This is wrong, and it makes it difficult to use Eiffel assemblies
                        correctly from other .NET languages.

                        - Peter Gummer
                      • Peter Gummer
                        ... No, thanks for the suggestion but that would be worse, because then our projects would compile on my machine, but nowhere else. It s much easier to keep
                        Message 11 of 20 , Aug 10, 2010
                        View Source
                        • 0 Attachment
                          On 11/08/2010, at 7:00, Emmanuel Stapf [ES] wrote:

                          > Wouldn't it be simpler to fix the broken 6.4 gobo_kernel.ecf in your
                          > own delivery
                          > of EiffelStudio?

                          No, thanks for the suggestion but that would be worse, because then
                          our projects would compile on my machine, but nowhere else.

                          It's much easier to keep two separate copies of the ECF for each
                          project, as I'm doing now, until we've reached any appropriate time in
                          our release cycle to upgrade from 6.4 to 6.6. That way, the upgrade
                          work affects nobody but me.

                          By the way, I successfully compiled our projects in 6.6 standard mode
                          yesterday. Our main application appears to be running correctly and
                          our unit tests pass. Exactly the same code (apart from the ECF "gobo"
                          changes) is currently running in both 6.4 and 6.6. The fact that I've
                          managed to get to this state is testimony to the fact that your
                          upgrade plan has worked for us (disregarding the ECF "gobo" glitch).
                          It took about 10 hours of work to achieve this, probably the most
                          difficult EiffelStudio upgrade I've done.

                          - Peter Gummer
                        • Emmanuel Stapf [ES]
                          ... Maybe I m being picky but this is not just an upgrade, it is an upgrade combined with a major library change for void-safety. The upgrade to 6.6 compatible
                          Message 12 of 20 , Aug 10, 2010
                          View Source
                          • 0 Attachment
                            > It took about 10 hours of work to achieve this, probably the most
                            > difficult EiffelStudio upgrade I've done.

                            Maybe I'm being picky but this is not just an upgrade, it is an upgrade combined
                            with a major library change for void-safety. The upgrade to 6.6 compatible mode
                            would have been straightforward and this is why we are proposing two modes so that
                            the pain of updating your code can be spread rather than imposed on you.

                            Regards,
                            Manu
                          • Emmanuel Stapf [ES]
                            ... Because in Eiffel nothing is definitely private and because to allow multiple inheritance and still show a sensible interface to other .NET languages we
                            Message 13 of 20 , Aug 10, 2010
                            View Source
                            • 0 Attachment
                              > That doesn't solve the mystery, however. Why are all of the secret
                              > features of our Eiffel classes included in the public .NET interface?
                              > This is wrong, and it makes it difficult to use Eiffel assemblies
                              > correctly from other .NET languages.

                              Because in Eiffel nothing is definitely private and because to allow multiple
                              inheritance and still show a sensible interface to other .NET languages we had no
                              choice but to perform dynamic calls via the .NET interface mechanism. Therefore
                              everything is public.

                              Regards,
                              Manu
                            • Peter Gummer
                              ... Let s see if I understand, Manu. It s true that Eiffel has no equivalent of .NET s private . An Eiffel feature that is secret would correspond to a
                              Message 14 of 20 , Aug 10, 2010
                              View Source
                              • 0 Attachment
                                Emmanuel Stapf [ES] wrote:

                                >> That doesn't solve the mystery, however. Why are all of the secret
                                >> features of our Eiffel classes included in the public .NET interface?
                                >> This is wrong, and it makes it difficult to use Eiffel assemblies
                                >> correctly from other .NET languages.
                                >
                                > Because in Eiffel nothing is definitely private and because to allow
                                > multiple
                                > inheritance and still show a sensible interface to other .NET
                                > languages we had no
                                > choice but to perform dynamic calls via the .NET interface
                                > mechanism. Therefore
                                > everything is public.

                                Let's see if I understand, Manu.

                                It's true that Eiffel has no equivalent of .NET's "private". An Eiffel
                                feature that is secret would correspond to a "protected" member
                                in .NET. Therefore, the obvious thing to have done would have been to
                                have made all secret Eiffel features "protected". Unfortunately,
                                however, this would only allow for single inheritance between the
                                Eiffel classes and so, as you pointed out, in order to allow one
                                Eiffel class to have multiple parents, you had to use .NET interfaces.
                                This allows the child class to access the secret features of all of
                                its parents, which is a very good thing.

                                So all features are public.

                                This arrangement makes sense for allowing Eiffel classes to work
                                together, but it makes no sense for C# or VB client classes to have
                                access to those secret features. Furthermore, C# or VB classes can
                                only inherit from one class, so a class written in those languages
                                that inherited from an Eiffel class would not need this interface
                                mechanism in order to access the parent class's "protected" (i.e.
                                secret) features.

                                In other words, all features are public only in order to satisfy the
                                Eiffel classes. It's an internal, Eiffel-specific mechanism. Single
                                inheritance languages don't need to see those interfaces, and the fact
                                that they can see those interfaces is actually damaging.

                                .NET has a concept called "internal". Anything declared "internal" is
                                visible only within the same assembly in which it is declared. Let's
                                imagine, then, that these Eiffel interfaces were declared "internal":
                                * Each Eiffel class within the assembly would still be able to see all
                                of the interfaces. The simulation of multiple inheritance would still
                                work.
                                * C# and VB classes outside the assembly would not be able to see the
                                interfaces.

                                This seems to me to be the basis for fixing this problem that C# and
                                VB classes are exposed to the Eiffel classes' secret features. The
                                simplistic proposal I've just made closes off various potentially
                                useful things. It would prevent Eiffel classes in one assembly from
                                multiply inheriting from Eiffel classes in other assemblies; but does
                                anyone build systems with multiple Eiffel assemblies anyway, given
                                that you have to create precompiled libraries in order for one Eiffel
                                assembly to use another Eiffel assembly? My proposal would likewise
                                prevent any other multiple inheritance language out there from using
                                Eiffel classes via multiple inheritance; but is there seriously anyone
                                out there who wants to do that? I think that, 90% of the time, this
                                proposal to use "internal" interfaces would be a big improvement. For
                                the remaining 10%, there could be a compiler option to make them
                                public as they are now.

                                - Peter Gummer
                              • Peter Gummer
                                ... Thanks for pointing that out, Manu. We could have delayed making the move, but we have to make the move sometime, and 6.6 strongly encourages us to move
                                Message 15 of 20 , Aug 10, 2010
                                View Source
                                • 0 Attachment
                                  Emmanuel Stapf [ES] wrote:

                                  > Maybe I'm being picky but this is not just an upgrade, it is an
                                  > upgrade combined
                                  > with a major library change for void-safety. The upgrade to 6.6
                                  > compatible mode
                                  > would have been straightforward and this is why we are proposing two
                                  > modes so that
                                  > the pain of updating your code can be spread rather than imposed on
                                  > you.

                                  Thanks for pointing that out, Manu. We could have delayed making the
                                  move, but we have to make the move sometime, and 6.6 strongly
                                  encourages us to move now.

                                  There's one factor that's crucial here. We don't want complex
                                  instructions for building our projects. Given a clean machine, we want
                                  the instructions for building our software to be:
                                  1. Install EiffelStudio 6.x.
                                  2. Check the source code out of Subversion repository xxxx.
                                  3. Run EiffelStudio 6.x, open project pppp, and compile.

                                  In 6.4, we don't want any special instructions about selecting
                                  "experimental" mode. In 6.6, we don't want any special instructions
                                  about selecting "compatible" mode. That kind of thing is likely to
                                  accumulate a whole lot more wasted hours through confusion and slip-
                                  ups, over time, than the time I've devoted to doing the upgrade. And,
                                  as a bonus, we are now using the new, void-safe libraries :-)

                                  - Peter Gummer
                                • Emmanuel Stapf [ES]
                                  ... As you pointed out, it would prevent using precompiled libraries under .NET. This mechanism is actually extensively used for our own internal testing as
                                  Message 16 of 20 , Aug 12, 2010
                                  View Source
                                  • 0 Attachment
                                    > .NET has a concept called "internal". Anything declared "internal" is
                                    > visible only within the same assembly in which it is declared. Let's
                                    > imagine, then, that these Eiffel interfaces were declared "internal":
                                    > * Each Eiffel class within the assembly would still be able to see all
                                    > of the interfaces. The simulation of multiple inheritance would still
                                    > work.
                                    > * C# and VB classes outside the assembly would not be able to see the
                                    > interfaces.
                                    >
                                    > This seems to me to be the basis for fixing this problem that C# and
                                    > VB classes are exposed to the Eiffel classes' secret features. The
                                    > simplistic proposal I've just made closes off various potentially
                                    > useful things. It would prevent Eiffel classes in one assembly from
                                    > multiply inheriting from Eiffel classes in other assemblies; but does
                                    > anyone build systems with multiple Eiffel assemblies anyway, given

                                    As you pointed out, it would prevent using precompiled libraries under .NET. This
                                    mechanism is actually extensively used for our own internal testing as well as for
                                    our CodeDOM and ASP.NET implementation.

                                    > proposal to use "internal" interfaces would be a big improvement. For
                                    > the remaining 10%, there could be a compiler option to make them
                                    > public as they are now.

                                    We could probably have that option but I'll have it the other way around because
                                    for normal Eiffel users it could results in errors hard to diagnose. Whereas if
                                    you are building an Eiffel assembly to use for other languages you might be more
                                    aware of that kind of issues. Therefore by default it is always public and if you
                                    do not want that, you can add the option to make them internal.

                                    Regards,
                                    Manu
                                  • Peter Gummer
                                    ... That would be great. We would definitely use that option. I ll submit a feature request for this. - Peter Gummer
                                    Message 17 of 20 , Aug 12, 2010
                                    View Source
                                    • 0 Attachment
                                      Emmanuel Stapf [ES] wrote:

                                      >> proposal to use "internal" interfaces would be a big improvement. For
                                      >> the remaining 10%, there could be a compiler option to make them
                                      >> public as they are now.
                                      >
                                      > We could probably have that option but I'll have it the other way
                                      > around because
                                      > for normal Eiffel users it could results in errors hard to diagnose.
                                      > Whereas if
                                      > you are building an Eiffel assembly to use for other languages you
                                      > might be more
                                      > aware of that kind of issues. Therefore by default it is always
                                      > public and if you
                                      > do not want that, you can add the option to make them internal.

                                      That would be great. We would definitely use that option.

                                      I'll submit a feature request for this.

                                      - Peter Gummer
                                    • Peter Gummer
                                      ... Actually, Manu, I ve had a second thought about this. There are two scenarios: 1. Multiple Eiffel .NET assemblies that need to call each other. For this to
                                      Message 18 of 20 , Aug 12, 2010
                                      View Source
                                      • 0 Attachment
                                        Emmanuel Stapf [ES] wrote:

                                        > As you pointed out, it would prevent using precompiled libraries
                                        > under .NET. ...
                                        > We could probably have that option but I'll have it the other way
                                        > around because
                                        > for normal Eiffel users it could results in errors hard to diagnose.
                                        > Whereas if
                                        > you are building an Eiffel assembly to use for other languages you
                                        > might be more
                                        > aware of that kind of issues. Therefore by default it is always
                                        > public and if you
                                        > do not want that, you can add the option to make them internal.

                                        Actually, Manu, I've had a second thought about this.

                                        There are two scenarios:

                                        1. Multiple Eiffel .NET assemblies that need to call each other. For
                                        this to work, you need precompiled libraries, and all interfaces
                                        within each precompiled library must be "public" so that multiple
                                        inheritance can work across assemblies.

                                        2. A single Eiffel .NET assembly that is intended to be called only by
                                        single-inheritance languages (C#, VB, etc.). For this to work, you
                                        just need a normal .NET DLL, and all interfaces within the DLL should
                                        be "internal" so that multiple inheritance can work within the
                                        assembly while not exposing secret features to C# and VB classes.

                                        There is a clean correspondence between the two scenarios and the kind
                                        of library that has to be built. There's no need for a new project
                                        option.

                                        So what I propose is this:

                                        1. When building a .NET precompiled library, the compiler should
                                        create "public" interfaces, as it does now.

                                        2. When building a normal .NET assembly, the compiler should create
                                        "internal" interfaces.

                                        - Peter Gummer
                                      Your message has been successfully submitted and would be delivered to recipients shortly.