Re: Re: suggestions for newbee

On Fri, 8 Jul 2005, David Bernard said:
 > Rohan Hart wrote:
 >> On Thu, 7 Jul 2005, David Bernard said:
 >> > prj2/
 >> >     lib/
 >> >        prj1.jar
 >> >     src/nice/
 >> >        int.addon.nice //addon to int
 >> 
 >> This is outside a package - how is it included?  Nice imports
 >> packages, not jars.
 >
 > What I understand is that nice work like C (import == inluce). If I
 > define in one package an Abstract Interface and function that use
 > instance (implements the abstract interface), then all implementation of
 > the Abstract Interface must be imported into the package ?

[big snip]

 > main() should work or not ? (main doesn't import pkg2 where abstract
 > interface is hook on Throwable)

That example looks fine.  However the original example adds methods on
'int' which has no package so can't be imported.  Placing 'int' into a
package like nice.lang solves that but there's still the problem of
*requiring* new methods to be in the nice.lang package.

 >> >        pkg2.pkg22/
 >> >           MyClassA.nice // an other class than pkg1.pkg11.pkg111.MyClassA
 >> >           MyClassC.nice
 >> >        pkg1.pkg11.pkg111
 >> >           MyClassA.addon.nice // definition of addons (methods, abstract
 >> > interface) to the MyClassA define in prj1
 >> 
 >> These add-ons should not *need* to be defined in the original package
 >> as that makes security harder.  Think of what Java would be like if
 >> classes could *only* be extended within their package.
 >> 
 > Addon isn't inheritence (extends in java), Addon impact the original class.

No, it's not inheritance but it also doesn't impact the original
class.  Security-wise, this new code is most likely written by a
different party from that original class so it shouldn't be given
access to its internals (not that Nice actually does this).
Attribution is, by the normal coding standards, also based on
package.  Then there's the issue of which class a multi-dispatched
method actually belongs to...

 > Currently I don't know the absolute solution against duplication :-(
 > But it's helpfull to know where implementation could be (target Class or
 > parent) ? Against language like C where function could be anywhere (and
 > where each team select a convention like prefix the method name by the
 > base filename...)

I'd still like there to be one file per package but the import/export
system would have to be beefed up.

Rohan



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar