On Mon, Jul 26, 2010 at 1:27 PM, Sven Barth <[email protected]> wrote: > On 26.07.2010 18:17, Martin wrote: >> >> That can be interpreted as following: >> >> The search path becomes the namespace => by defining an alias for a >> search path >> -Fu=LCL::/path/to/lcl >> the alias "LCL" has been defined, to include all unist in this search path >> >> using a unit from a anmespace is done with the existing "IN" operator >> (which needs to be extended to support this, and which needs to be >> allowed to be used in the scope) >> uses Buttons in 'LCL'; >> >> Conflicts in names are solved by aliases. Therefore there never is a >> need to specify a fully qualified name "LCL.Buttons" (such a name does >> not exist / can not even be used). Instead the alias is used. >> >> all solved. >> No new syntax elements needed (except for alias) >> >> --------- >> Advantage over namspaces: >> >> Namespaces send the (wrong) message: the developper does no longer need >> to care about clashes. >> that message is wrong, because: >> 1) one name => many units => unreadable >> 2) while unitname clashes can be solved => namespace-name clashes can >> not be solved >> That message also leads to using names that are more likely to clash, >> resulting in more clashes, that require more fully qualified names.... >> >> >> using IN and ALIAS, >> - the developper should still attempt to use names that he hopes to be >> unique: MyFooStrUtils,instead of StrUtils >> - only in the rare case of a conflict, action is needed > > Well... now that I know how you want those "in 'LCL'" things to work I tend > to prefer your solution... (I'm easy to convince, I know ^^). > > Also it's backwards compatible if it is not used. Nice :D
This is cool, but duplicate names may still exist. MD _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/mailman/listinfo/fpc-devel
