Smalltalk › Cincom › VisualWorks

Namespaces (Was: MNU in tools after loading parcel)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

mkobetic

Namespaces (Was: MNU in tools after loading parcel)

As a general rule of thumb you should not use fully qualified names in code. They should be unnecessary if your imports are set up correctly. The problem is that most code starts off by importing Smalltalk.* (even if you're putting it into a namespace of your own). For backward compatibility reasons Smalltalk is a "kitchen sink" namespace importing everything that it had before namespaces. Consequently importing Smalltalk into your namespace immediately turns your namespace into a kitchen sink as well. We need to move away from importing Smalltalk towards importing the more specific namespaces. Most applications (especially new ones) should switch from importing Smalltalk.* to importing Core.* and whatever other namespaces they need (Graphics, UI, OS, ....) or specific class imports if they need only few.

The tools are slowly evolving towards that. Nowadays when you reference a name that isn't in your scope you'll get a series of dialogs guiding you towards the right decision. Unfortunately, the beginning of that sequence is kinda obscured at the moment, it starts with the "Correct spelling" button in the initial dialog. It first lets you find the global name you're looking for and then gives you some choices of importing the name or its whole namespace, importing it into your home namespace or into the class that your're editing, etc. I think (once polished) this is a promising way to help building proper import structure gradually. I'd recommend modifying the Create Class/Namespace templates to import Core.* instead of Smalltalk.* initially and then let the tools guide you in adding more imports as you build up your code.

Of course, this would be more difficult if you have a large body of code already. We may need additional tools to allow switching from the "kitchen sink" setup to a "managed" import structure for that. And we'll likely have to keep Smalltalk as the "kitchen sink" namespace forever for that large body of existing code where expending the effort to "make it cleaner" from the namespace point of view just doesn't make economic sense.

The above won't eliminate name conflicts but it will reduce the occurrences significantly, as the namespaces will be a lot cleaner without the Smalltalk entanglement. When you do get a name conflict despite that, it doesn't have to be resolved using a long name still. I think the right way to go about it is to decide what do you want the name to mean in your specific context and then resolve the conflict so that it is so, generally by avoiding or overriding the import of the other name. The techniques you can use for that are:

a) specific imports trump generic imports, so you give one name a preference by importing it specifically. That will of course effectively hide the other name so if you need it you'll need to do b) for it

b) you can use a name without importing it by defining your own alias for it, i.e. add a shared in your namespace with
non-conflicting name whose value will be the value of the name in the other namespace, then use your local name instead

With these guidelines in mind, I think that it should be possibly to avoid full names in vast majority (if not all) cases.

HTH,

Martin

"Steffen Märcker"<[hidden email]> wrote:

> Dear Alan, Dear Helge,
>
> of course it is advisable to put my classes into a namespace - which I
> actually did now. I just wonder why some of the base system classes are
> being used prefixed and others not. Perhaps there could be a warning or
> something similar when you create a class in Smalltalk with a name already
> used _and_ referenced without a prefix elsewhere.
>
> Regards,
> Steffen
>
>
> Am 21.12.2010, 18:44 Uhr, schrieb Nowak, Helge <[hidden email]>:
>
> >> From my point of view you can never be sure that at any point in time
> >> the System will not have a class that has the same name as yours.
> >> Therefore I'd call it a good practice to have all my classes in my
> >> namespace.
> >
> > Cheers
> > Helge
> >
> > -----Ursprüngliche Nachricht-----
> > Von: [hidden email] [mailto:[hidden email]] Im
> > Auftrag von Alan Knight
> > Gesendet: Dienstag, 21. Dezember 2010 16:37
> > An: [hidden email]
> > Betreff: Re: [vwnc] MNU in tools after loading parcel
> >
> > I think part of the point of the namespace mechanism is that if you're
> > introducing classes of your own which have names the same as those in
> > basic Smalltalk, that you can put them in your own namespaces and they
> > won't conflict with the base. The design which took everything out of
> > the Smalltalk namespace and put it into sub-namespaces which were then
> > all imported into Smalltalk so they might as well have been there anyway
> > is questionable. But I certainly wouldn't want to see all references to
> > base system classes need to be prefixed. In general, I'd like to avoid
> > having to use prefixes. Why wouldn't you just create your class in an
> > application namespace?
> >
> > I suspect the reason you see that on one platform but not on another
> > might be because the order of lookup is not strictly deterministic, so
> > you might get references resolving to one class on one platform and
> > another on another. But that's complete speculation on my part, and I'm
> > not sure what would make the order actually change if you just moved an
> > image from one platform to another.
> >
> > On 2010-12-21 8:16 AM, Steffen Märcker wrote:
> >> Sorry, my fault. I mean Graphics.Pattern, of course. -_-'
> >>
> >> Steffen
> >>
> >>
> >>> Ok,
> >>>
> >>> one step further I see several references to Graphics.Image which are
> >>> not
> >>> prefixed with the namespace 'Graphics'. I think the get resolved to my
> >>> class at it doesn't reside inside a namespace other than 'Smalltalk'.
> >>> If
> >>> this observation is correct I suggest to correct the references in the
> >>> base image in order to prevent those problems in general.
> >>> Any opinions on this?
> >>>
> >>> Regards, Steffen
> >>>
> >>>
> >>> Am 21.12.2010, 12:08 Uhr, schrieb Nowak, Helge<[hidden email]>:
> >>>
> >>>> I tried on Windows 7:
> >>>> - If I create the Pattern class as a subclass of Object in my private
> >>>> namespace there is no problem
> >>>> - If I create the Pattern class as a subclass of Object in the
> >>>> Smalltalk
> >>>> namespace I get on parcel publishing the infinite number of "MNU:
> >>>> #from:" as you are seeing on parcel load
> >>>>
> >>>>
> >>>> -----Ursprüngliche Nachricht-----
> >>>> Von: [hidden email] [mailto:[hidden email]] Im
> >>>> Auftrag von Steffen Märcker
> >>>> Gesendet: Dienstag, 21. Dezember 2010 11:54
> >>>> An: vwnc
> >>>> Betreff: Re: [vwnc] MNU in tools after loading parcel
> >>>>
> >>>> Hi,
> >>>>
> >>>> I've got a step further. (Thanks to L. William!) The problems are
> >>>> caused
> >>>> by the following class I've defined:
> >>>>
> >>>> Class Smalltalk.Pattern
> >>>> Superclass: Core.Object
> >>>> ...
> >>>>
> >>>> It seems to interfere with either Graphics.Pattern or XML.Pattern on
> >>>> Windows. This seems odd to me because on Mac everything works
> >>>> smoothly.
> >>>> Is
> >>>> this a know bug or a limitation on Windows?
> >>>>
> >>>> Regards, Steffen
> >>>>
> >>>>
> >>>>
> >>>> Am 21.12.2010, 10:07 Uhr, schrieb Linus Willmann<[hidden email]>:
> >>>>
> >>>>> Steffen,
> >>>>>
> >>>>> I'd suggest, to create a source file-In from the parcel& file-in
> >>>>> method
> >>>>> by method - each time creating the activities to raise the error -to
> >>>>> find the cause.
> >>>>>
> >>>>> Kind regards,
> >>>>> L. Willmann
> >>>>>
> >>>>> ----- Original Message ----- From: "Steffen Märcker"<[hidden email]>
> >>>>> To: "vwnc"<[hidden email]>; "Steffen Märcker"<[hidden email]>
> >>>>> Sent: Tuesday, December 21, 2010 9:55 AM
> >>>>> Subject: Re: [vwnc] MNU in tools after loading parcel
> >>>>>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> has anybody some ideas how I can investigate what's going on?
> >>>>>
> >>>>> Regards,
> >>>>> Steffen
> >>>>>
> >>>>> Am 20.12.2010, 17:10 Uhr, schrieb Steffen Märcker<[hidden email]>:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> I've created the attached package on Mac (that library isn't
> >>>>>> finished
> >>>>>> yet)
> >>>>>> and attempted to load it into images on Windows. Loading the parcel
> >>>>>> seems
> >>>>>> to be successful. Unfortunately the image gets into an endless loop
> >>>>>> of
> >>>>>> opening exceptions notifiers with an MNU ( #from: ) if I use e.g.
> >>>>>> the
> >>>>>> browser. For example, try to create a new protocol in some class
> >>>>>> (not
> >>>>>> necessarily from this package) and the endless loop starts.
> >>>>>> I've absolutely no idea what's going on and debugging seems to be
> >>>>>> impossible. Even stranger, on Mac nothing like this happens.
> >>>>>>
> >>>>>> Please help!
> >>>>>>
> >>>>>> THX,
> >>>>>> Steffen
> >>>>> _______________________________________________
> >>>>> vwnc mailing list
> >>>>> [hidden email]
> >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> >>>>>
> >>>> _______________________________________________
> >>>> vwnc mailing list
> >>>> [hidden email]
> >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> >>> _______________________________________________
> >>> vwnc mailing list
> >>> [hidden email]
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> >> _______________________________________________
> >> vwnc mailing list
> >> [hidden email]
> >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: Namespaces (Was: MNU in tools after loading parcel)

On 12/22/2010 6:04 PM, [hidden email] wrote:
> [...strategy towards cleaner namespace use...]
> The above won't eliminate name conflicts but it will reduce the occurrences significantly, as the namespaces will be a lot cleaner without the Smalltalk entanglement. When you do get a name conflict despite that, it doesn't have to be resolved using a long name still. I think the right way to go about it is to decide what do you want the name to mean in your specific context and then resolve the conflict so that it is so, generally by avoiding or overriding the import of the other name.
The current namespace implementation gives us this weird construct of
'Ambiguous reference'.
It seems this construct introduces a sort of brittleness that we can do
without. (If I load a third-party package that is unrelated to my code
it may invalidate my code because one of my references suddenly becomes
'ambiguous').

If the imports mechanism were altered to declare imports as a stack
instead of a set, and the lookup rules are altered to stop searching
after its first (nearest!) match this class of brittleness goes away.
Instead it is replaced with a more manageable one that runs parallel to
the brittleness scenarios we know in class inheritance. (Indeed the
whole name import mechanism will feel a lot more like the method lookup
rules we already know very well).

So I propose that import declarations be interpreted as an import stack
instead of an import set, and note that then technique a) below becomes
default/automatic without us needing to know any rules about what 'type
of import trumps another type' -- simply because that would be explicit
in the ordering in an import declaration.

There is a silver lining to the 'ambiguous reference' construct: it has
pushed existing projects to evolve such that these reference don't occur
much anymore.
This entails that simply altering the interpretation of import
declarations as described above may actually work for most (if not all)
existing projects!

R
-

> The techniques you can use for that are:
>
> a) specific imports trump generic imports, so you give one name a preference by importing it specifically. That will of course effectively hide the other name so if you need it you'll need to do b) for it
>
> b) you can use a name without importing it by defining your own alias for it, i.e. add a shared in your namespace with
> non-conflicting name whose value will be the value of the name in the other namespace, then use your local name instead
>
> With these guidelines in mind, I think that it should be possibly to avoid full names in vast majority (if not all) cases.
>
> HTH,
>
> Martin
>
> "Steffen Märcker"<[hidden email]> wrote:
>> Dear Alan, Dear Helge,
>>
>> of course it is advisable to put my classes into a namespace - which I
>> actually did now. I just wonder why some of the base system classes are
>> being used prefixed and others not. Perhaps there could be a warning or
>> something similar when you create a class in Smalltalk with a name already
>> used _and_ referenced without a prefix elsewhere.
>>
>> Regards,
>> Steffen
>>
>>
>> Am 21.12.2010, 18:44 Uhr, schrieb Nowak, Helge<[hidden email]>:
>>
>>>> From my point of view you can never be sure that at any point in time
>>>> the System will not have a class that has the same name as yours.
>>>> Therefore I'd call it a good practice to have all my classes in my
>>>> namespace.
>>> Cheers
>>> Helge
>>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: [hidden email] [mailto:[hidden email]] Im
>>> Auftrag von Alan Knight
>>> Gesendet: Dienstag, 21. Dezember 2010 16:37
>>> An: [hidden email]
>>> Betreff: Re: [vwnc] MNU in tools after loading parcel
>>>
>>> I think part of the point of the namespace mechanism is that if you're
>>> introducing classes of your own which have names the same as those in
>>> basic Smalltalk, that you can put them in your own namespaces and they
>>> won't conflict with the base. The design which took everything out of
>>> the Smalltalk namespace and put it into sub-namespaces which were then
>>> all imported into Smalltalk so they might as well have been there anyway
>>> is questionable. But I certainly wouldn't want to see all references to
>>> base system classes need to be prefixed. In general, I'd like to avoid
>>> having to use prefixes. Why wouldn't you just create your class in an
>>> application namespace?
>>>
>>> I suspect the reason you see that on one platform but not on another
>>> might be because the order of lookup is not strictly deterministic, so
>>> you might get references resolving to one class on one platform and
>>> another on another. But that's complete speculation on my part, and I'm
>>> not sure what would make the order actually change if you just moved an
>>> image from one platform to another.
>>>
>>> On 2010-12-21 8:16 AM, Steffen Märcker wrote:
>>>> Sorry, my fault. I mean Graphics.Pattern, of course. -_-'
>>>>
>>>> Steffen
>>>>
>>>>
>>>>> Ok,
>>>>>
>>>>> one step further I see several references to Graphics.Image which are
>>>>> not
>>>>> prefixed with the namespace 'Graphics'. I think the get resolved to my
>>>>> class at it doesn't reside inside a namespace other than 'Smalltalk'.
>>>>> If
>>>>> this observation is correct I suggest to correct the references in the
>>>>> base image in order to prevent those problems in general.
>>>>> Any opinions on this?
>>>>>
>>>>> Regards, Steffen
>>>>>
>>>>>
>>>>> Am 21.12.2010, 12:08 Uhr, schrieb Nowak, Helge<[hidden email]>:
>>>>>
>>>>>> I tried on Windows 7:
>>>>>> - If I create the Pattern class as a subclass of Object in my private
>>>>>> namespace there is no problem
>>>>>> - If I create the Pattern class as a subclass of Object in the
>>>>>> Smalltalk
>>>>>> namespace I get on parcel publishing the infinite number of "MNU:
>>>>>> #from:" as you are seeing on parcel load
>>>>>>
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: [hidden email] [mailto:[hidden email]] Im
>>>>>> Auftrag von Steffen Märcker
>>>>>> Gesendet: Dienstag, 21. Dezember 2010 11:54
>>>>>> An: vwnc
>>>>>> Betreff: Re: [vwnc] MNU in tools after loading parcel
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I've got a step further. (Thanks to L. William!) The problems are
>>>>>> caused
>>>>>> by the following class I've defined:
>>>>>>
>>>>>> Class Smalltalk.Pattern
>>>>>> Superclass: Core.Object
>>>>>> ...
>>>>>>
>>>>>> It seems to interfere with either Graphics.Pattern or XML.Pattern on
>>>>>> Windows. This seems odd to me because on Mac everything works
>>>>>> smoothly.
>>>>>> Is
>>>>>> this a know bug or a limitation on Windows?
>>>>>>
>>>>>> Regards, Steffen
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 21.12.2010, 10:07 Uhr, schrieb Linus Willmann<[hidden email]>:
>>>>>>
>>>>>>> Steffen,
>>>>>>>
>>>>>>> I'd suggest, to create a source file-In from the parcel& file-in
>>>>>>> method
>>>>>>> by method - each time creating the activities to raise the error -to
>>>>>>> find the cause.
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> L. Willmann
>>>>>>>
>>>>>>> ----- Original Message ----- From: "Steffen Märcker"<[hidden email]>
>>>>>>> To: "vwnc"<[hidden email]>; "Steffen Märcker"<[hidden email]>
>>>>>>> Sent: Tuesday, December 21, 2010 9:55 AM
>>>>>>> Subject: Re: [vwnc] MNU in tools after loading parcel
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> has anybody some ideas how I can investigate what's going on?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Steffen
>>>>>>>
>>>>>>> Am 20.12.2010, 17:10 Uhr, schrieb Steffen Märcker<[hidden email]>:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I've created the attached package on Mac (that library isn't
>>>>>>>> finished
>>>>>>>> yet)
>>>>>>>> and attempted to load it into images on Windows. Loading the parcel
>>>>>>>> seems
>>>>>>>> to be successful. Unfortunately the image gets into an endless loop
>>>>>>>> of
>>>>>>>> opening exceptions notifiers with an MNU ( #from: ) if I use e.g.
>>>>>>>> the
>>>>>>>> browser. For example, try to create a new protocol in some class
>>>>>>>> (not
>>>>>>>> necessarily from this package) and the endless loop starts.
>>>>>>>> I've absolutely no idea what's going on and debugging seems to be
>>>>>>>> impossible. Even stranger, on Mac nothing like this happens.
>>>>>>>>
>>>>>>>> Please help!
>>>>>>>>
>>>>>>>> THX,
>>>>>>>> Steffen
>>>>>>> _______________________________________________
>>>>>>> vwnc mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>>>>>
>>>>>> _______________________________________________
>>>>>> vwnc mailing list
>>>>>> [hidden email]
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>>> _______________________________________________
>>>>> vwnc mailing list
>>>>> [hidden email]
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>> _______________________________________________
>>>> vwnc mailing list
>>>> [hidden email]
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>

--
*********************************************************************

Dit e-mailbericht is alleen bestemd voor de geadresseerde(n).

Gebruik door anderen is niet toegestaan. Indien u niet degeadresseerde(n) bent wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Door de elektronische verzending kunnen aan de inhoud van dit bericht geen rechten worden ontleend.

Soops B.V. is gevestigd te Amsterdam, Nederland, en is geregistreerd bij de Kamer van Koophandel onder nummer 33240368.
Soops B.V. levert volgens de Fenit voorwaarden, gedeponeerd te Den Haag op 8 december 1994 onder nummer 1994/189.
**********************************************************************

This e-mail message is intended to be exclusively for the addressee.

If you are not the intended recipient you are kindly requested not to make any use whatsoever of the contents and to notify the sender immediately by returning this e-mail message. No rights can be derived from this message.

Soops B.V. is a private limited liability company and has its seat at Amsterdam, The Netherlands and is registered with the Trade Registry of the Chamber of Commerce and Industry under number 33240368.
Soops B.V. delivers according to the General Terms and Conditions of Business of Fenit, registered at The Hague, The Netherlands on December 8th, 1994, under number 1994/189
**********************************************************************

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

mkobetic

Re: Namespaces (Was: MNU in tools after loading parcel)

In reply to this post by mkobetic

I might be missing something, but AFAICS the proposed change doesn't actually prevent ambiguities. It just lays down a rule how to resolve them. That however doesn't necessarily mean that the resolution will always match what you want it to be. You're still open to the problem of someone modifying a namespace you're importing and suddenly changing the meaning of a name in your namespace, but this time without any warning. I suspect that what you're proposing was considered in the original design and rejected in favor of warning about ambiguities and forcing an explicit resolution.

"Reinout Heeck"<[hidden email]> wrote:

> The current namespace implementation gives us this weird construct of
> 'Ambiguous reference'.
> It seems this construct introduces a sort of brittleness that we can do
> without. (If I load a third-party package that is unrelated to my code
> it may invalidate my code because one of my references suddenly becomes
> 'ambiguous').
>
> If the imports mechanism were altered to declare imports as a stack
> instead of a set, and the lookup rules are altered to stop searching
> after its first (nearest!) match this class of brittleness goes away.
> Instead it is replaced with a more manageable one that runs parallel to
> the brittleness scenarios we know in class inheritance. (Indeed the
> whole name import mechanism will feel a lot more like the method lookup
> rules we already know very well).
>
> So I propose that import declarations be interpreted as an import stack
> instead of an import set, and note that then technique a) below becomes
> default/automatic without us needing to know any rules about what 'type
> of import trumps another type' -- simply because that would be explicit
> in the ordering in an import declaration.
>
> There is a silver lining to the 'ambiguous reference' construct: it has
> pushed existing projects to evolve such that these reference don't occur
> much anymore.
> This entails that simply altering the interpretation of import
> declarations as described above may actually work for most (if not all)
> existing projects!

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: Namespaces (Was: MNU in tools after loading parcel)

On 1/4/2011 3:18 PM, [hidden email] wrote:
> I might be missing something, but AFAICS the proposed change doesn't actually prevent ambiguities. It just lays down a rule how to resolve them.

IOW, from the perspective of the system ambiguities don't exist: all
code/classes dealing with detecting ambiguities can be removed.

So we are saying the same thing -- form a different perspective.

To drive it home: the system has no implementation to model 'ambiguous
method' in a class hierarchy, so why does it have/need a model for
'ambiguous reference' in a namespace import structure?

> That however doesn't necessarily mean that the resolution will always match what you want it to be. You're still open to the problem of someone modifying a namespace you're importing and suddenly changing the meaning of a name in your namespace, but this time without any warning.
Exactly as could happen when some package extends a superclass of one of
my application classes.

> I suspect that what you're proposing was considered in the original design and rejected in favor of warning about ambiguities and forcing an explicit resolution.
Exactly, my comment was intended as feedback on that very decision:
in practice we find that the system throws non-errors in our face
long after we coded up a module.
Forcing resolution of non-problems is where this went awry.

If the proposed lookup architecture were used a lot of those purported
ambiguities would not arise (as in: they would get resolved as
originally intended),
of course some would still lead to errors.
The important point is that we get less false positives -- particularly
ages after we finalized a code module.
The lesser point is that the mental model is much simpler to adopt
because it aligns with that of method resolution (an associated
brittleness problems).

HTH,

R
-

> "Reinout Heeck"<[hidden email]> wrote:
>> The current namespace implementation gives us this weird construct of
>> 'Ambiguous reference'.
>> It seems this construct introduces a sort of brittleness that we can do
>> without. (If I load a third-party package that is unrelated to my code
>> it may invalidate my code because one of my references suddenly becomes
>> 'ambiguous').
>>
>> If the imports mechanism were altered to declare imports as a stack
>> instead of a set, and the lookup rules are altered to stop searching
>> after its first (nearest!) match this class of brittleness goes away.
>> Instead it is replaced with a more manageable one that runs parallel to
>> the brittleness scenarios we know in class inheritance. (Indeed the
>> whole name import mechanism will feel a lot more like the method lookup
>> rules we already know very well).
>>
>> So I propose that import declarations be interpreted as an import stack
>> instead of an import set, and note that then technique a) below becomes
>> default/automatic without us needing to know any rules about what 'type
>> of import trumps another type' -- simply because that would be explicit
>> in the ordering in an import declaration.
>>
>> There is a silver lining to the 'ambiguous reference' construct: it has
>> pushed existing projects to evolve such that these reference don't occur
>> much anymore.
>> This entails that simply altering the interpretation of import
>> declarations as described above may actually work for most (if not all)
>> existing projects!
>

mkobetic

Re: Namespaces (Was: MNU in tools after loading parcel)

In reply to this post by mkobetic

"Reinout Heeck"<[hidden email]> wrote:

> > I suspect that what you're proposing was considered in the original design and rejected in favor of warning about ambiguities and forcing an explicit resolution.
> Exactly, my comment was intended as feedback on that very decision:
> in practice we find that the system throws non-errors in our face
> long after we coded up a module.
> Forcing resolution of non-problems is where this went awry.
>
>
> If the proposed lookup architecture were used a lot of those purported
> ambiguities would not arise (as in: they would get resolved as
> originally intended),
> of course some would still lead to errors.
> The important point is that we get less false positives -- particularly
> ages after we finalized a code module.

Fair enough. Are you saying that in your experience you get more false positives than true ones ? To be honest I can't confirm or deny that from my experience. But I'm not saying that somehow invalidates yours, we just deal with different type of codebases. It would be useful to have more feedback on the issue to make the call one way or the other. Any others want to chime in ?

> The lesser point is that the mental model is much simpler to adopt
> because it aligns with that of method resolution (an associated
> brittleness problems).

I'm not entirely convinced that the method lookup analogy is valid in our case. If namespaces were implemented as classes, then sure, but that's not the case in VW. If you want to say that imports are like inheritance, then you immediately have multiple vs single inheritance for example. Anyway, I get your point, I'm just not sure if interpreting name lookup in VW as a variant of method lookup is more helpful or confusing.

Cheers,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Niall Ross

Re: Namespaces (Was: MNU in tools after loading parcel)

In reply to this post by Reinout Heeck-2

Dear Reinout,

> If the imports mechanism were altered to declare imports as a stack
> instead of a set, and the lookup rules are altered to stop searching
> after its first (nearest!) match ...

FYI, my FirstFindNameSpace in package Porting-Namespaces implements this
strategy. (The latest version works in 7.7.1; read the blessing
comments for which version to use in older VW releases.)

The idea is that when importing an application from a single-namespace
dialect, there is necessarily a correct order of imports for which this
strategy works. You can therefore get the application working by
importing it into a FirstFindNameSpace (and fixing everything else),
then either leave it there or move it into a standard namespace and
resolve ambiguities.

I agree with Martin that in a more general situation, you do not
necessarily know whether the first found is what you want, so it may ne
worth being warned of ambiguities that appear. However, is it that you
see that as more a code tools thing, like seeing a symbol warning your
method overrides one further up the hierarchy, rather than a
throw-exception thing?

I certainly created the FirstFindNameSpace to avoid false positives
during porting exercises (when there is plenty else to resolve).

Yours faithfully
Niall Ross

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: Namespaces (Was: MNU in tools after loading parcel)

In reply to this post by mkobetic

On 1/4/2011 4:38 PM, [hidden email] wrote:

> "Reinout Heeck"<[hidden email]> wrote:
>>> I suspect that what you're proposing was considered in the original design and rejected in favor of warning about ambiguities and forcing an explicit resolution.
>> Exactly, my comment was intended as feedback on that very decision:
>> in practice we find that the system throws non-errors in our face
>> long after we coded up a module.
>> Forcing resolution of non-problems is where this went awry.
>>
>>
>> If the proposed lookup architecture were used a lot of those purported
>> ambiguities would not arise (as in: they would get resolved as
>> originally intended),
>> of course some would still lead to errors.
>> The important point is that we get less false positives -- particularly
>> ages after we finalized a code module.
> Fair enough. Are you saying that in your experience you get more false positives than true ones ?

Yes, by a rather large margin.
I'll ask around tomorrow to hear the opinion of my coworkers.

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout Heeck-2

Re: Namespaces (Was: MNU in tools after loading parcel)

In reply to this post by Niall Ross

On 1/4/2011 4:59 PM, Niall Ross wrote:
>
> I agree with Martin that in a more general situation, you do not
> necessarily know whether the first found is what you want, so it may
> ne worth being warned of ambiguities that appear. However, is it that
> you see that as more a code tools thing, like seeing a symbol warning
> your method overrides one further up the hierarchy, rather than a
> throw-exception thing?

Yes, I expect that to be much more helpful. (provided we actually have
ordered lookup of course -- otherwise we still need to resolve it merely
to make the lookup deterministic).

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc