1. This whole namespace thing
- Posted by Michael Sabal <mjs at OSA.ATT.NE.JP> Apr 25, 1998
- 544 views
It's nice that the Euphoria community is growing so well that we have to = worry about conflicting include files written by the community. In no = other language I can think of has the language itself developed by the = users of the language. =20 So here's my humble contribution to this thread. We don't want to = change the core of Euphoria any more than we have to. Adding namespace = would mean changing the core, if handled internally as most people have = been suggesting. Why not make a consistent format for include files = that would prevent conflicts almost entirely. For example: -- foobar.e global constant FOO1 =3D 1 global constant FOO2 =3D 2 global constant BAR1 =3D 3 global constant BAR2 =3D 4 procedure foo1 (...) -- note that this is a LOCAL procedure function foo2 (...) procedure bar1 (...) procedure bar2 (...) global function foobar(atom code,sequence data) object returnable returnable =3D 0 if code =3D FOO1 then foo1(data) elsif code =3D FOO2 then returnable =3D foo2(data) elsif code =3D BAR1 then bar1(data) elsif code =3D BAR2 then bar2(data) else returnable =3D -1 -- which could be read as an error message return returnable -- obviously procedures return nothing, so this 0 = would -- be discarded. end function -------- This would keep the general efficiency of the language by avoiding the need for a preprocessor, keep Rob from having to modify the language, = and solve the namespace problem. =20 Of course this presents the two drawbacks of existing code (would = reverse compatibility be possible with the other suggestions?) and = slightly more work for the programmer (but only in that it forces us to = be a little more organized with our libraries). This also resembles OOP = a little, because all procedures/func's would be called as part of a = class: junk =3D foobar(BAR2,{}) using the tools already available as = opposed to a dot method. =20 Because of the wild nature of the recent threads on structures and OOP, = I'm going to avoid any further comments on that subject ;) NB: for the Christians on the list, I'm interested in any Euphoria = Bible tools you might have (except Bibles, I've already got 12MB worth). = =20 Serving Christ, Michael J. Sabal mjs at osa.att.ne.jp http://home.att.ne.jp/gold/mjs/index.html
2. Re: This whole namespace thing
- Posted by Kasey <kaeyb at GEOCITIES.COM> Apr 25, 1998
- 511 views
Michael Sabal wrote: > > It's nice that the Euphoria community is growing so well that we have to worry about conflicting >include files written by the community. In no other language I can think of has the language itself >developed by the users of the language. > > So here's my humble contribution to this thread. We don't want to change the core of Euphoria any >more than we have to. Adding namespace would mean changing the core, if handled internally as most >people have been suggesting. Why not make a consistent format for include files that would prevent >conflicts almost entirely. For example: > > -- foobar.e > > global constant FOO1 = 1 > global constant FOO2 = 2 > global constant BAR1 = 3 > global constant BAR2 = 4 > > procedure foo1 (...) -- note that this is a LOCAL procedure > > function foo2 (...) > > procedure bar1 (...) > > procedure bar2 (...) > > global function foobar(atom code,sequence data) > > object returnable > > returnable = 0 > > if code = FOO1 then > foo1(data) > elsif code = FOO2 then > returnable = foo2(data) > elsif code = BAR1 then > bar1(data) > elsif code = BAR2 then > bar2(data) > else > returnable = -1 -- which could be read as an error message > > return returnable -- obviously procedures return nothing, so this 0 would > -- be discarded. > > end function > > -------- > > This would keep the general efficiency of the language by avoiding the > need for a preprocessor, keep Rob from having to modify the language, and solve the > namespace problem. > Of course this presents the two drawbacks of existing code (would reverse >compatibility be possible with the other suggestions?) and slightly more work for the >programmer (but only in that it forces us to be a little more organized with our libraries). > This also resembles OOP a little, because all procedures/func's would be called as part of a >class: junk = foobar(BAR2,{}) using the tools already available as opposed to a dot method. > Because of the wild nature of the recent threads on structures and OOP, I'm going to > avoid any further comments on that subject ;) > > NB: for the Christians on the list, I'm interested in any Euphoria Bible tools you >might have (except Bibles, I've already got 12MB worth). > > Serving Christ, > Michael J. Sabal > mjs at osa.att.ne.jp > http://home.att.ne.jp/gold/mjs/index.html I like this one mostly. Not to far offsomthing I've done myself, though I had each new function add a human readable name to one part of a global list and their function id to the other part. of course they took data structured the same as each other and thier outputs were all a conssitant type too (filters for a graphics editing program I'm working on) global funtion blur(sequence image_chunk) sequence output,temp ----and so on ..... return output end function append (filter_A_list[1],"Standard Blur")--- this is at the top level of the include file append (filter_A_list[2],routine_id("blur")) of course this methode doesn't do anything about namespace, but if blur were not global and you had a function in the include file such as: global funtion do_filter(sequence data, integer f_num) return call_func(f_num,data) end function though this would defete one of the purposes of what >I< was trying to do (which needs the filter funcions visible at two includes away so I could shroud my source and others writing filters could shroud thier code and yet still get the two to co-operate by meerly adding include those_filters.e to and inlude file thats nothing more than alist of includes and is in turn include in the main prog that lists all the filters for the user to pick between (using filter_A_list[1])). But I digress (way to often way to much ;) ) these are do-able now solutions that don't break existing code or change Euphoria itself. Besides unless the euphoria community is gonnna 180 itslef and get insular and stop sharing code and ideas it's gonna need to devolpe general guidlines on a lot of code compatability issues anyway, not just namespaces. Of course we could all just add our intials to all our globals to (funtion KB_bar()) (just kiddding :) ) Kasey