From: David A. <dav...@gm...> - 2008-11-09 16:50:01
|
Rick McGuire wrote: > There's no name collision problem that I'm aware of. The names > involved here are the internal names defined in the package table. If > two classes use the same libraries and reuse the same backing native > methods, that will work just fine. Perhaps I'm missing something in > your point. Can you give a concrete example? > > Rick > > On Sun, Nov 9, 2008 at 11:38 AM, David Ashley > <dav...@gm...> wrote: > >> Mark Miesfeld wrote: >> >> On Sun, Nov 9, 2008 at 7:33 AM, Rick McGuire <obj...@gm...> wrote: >> >> >> >> I think there's one other change I need to consider. This is likely >> to lead so some interesting problems with >> case. For example, >> >> ::attribute foo EXTERNAL 'LIBRARY yada" >> >> will require "GETFOO" and "SETFOO", but this version >> >> ::attribute "Foo" EXTERNAL 'LIBRARY yada' >> >> will require "GETFoo" and "SetFoo". I think I'd like to make the >> resolution rules for resolving the procedures >> case insensitive. Since this resolution step is performed using a >> generated table, there are no platform implications >> to doing this, and I seriously double many people will want to define >> different methods using case to distinguish them. >> >> >> Good point. For this form, I think I would have expected the >> resolution to be case insensitive and would have only learned it >> wasn't through trial and error. >> >> -- >> Mark Miesfeld >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> >> I can see one potential problem with the this method definition. If two >> classes use the same external library then you will have a name collision >> using the this method for methods of the same name. This probably ok in 90% >> of the cases but there will always be that instance where one method needs >> to perform something special and then you have a problem. >> >> I think the potential confusion factor is kind of high for this kind of >> definition. I prefer an explicit definition of the external procedure. >> >> David Ashley >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > The point I was trying to make concernes the "special case" where a method in one of the classes need to perform special processing that the method of the same name in the other class neither needs or wants (for instance, additional argument checking). In that case you have an unresolvable collision in terms of functionality. I just think the potential confusion factor is too high. David Ashley |