Re: Re: suggestions for newbee

Rohan Hart wrote:

>Hi David
>
>On Thu, 7 Jul 2005, David Bernard said:
> >>> I forgot some note about 'class addon'. If I want/need to add some
> >>> method to Worker in another project/lib, then in the second project I
> >>> create a file Worker.addon.nice in the same directory hierarchy
> >>> (package) as the orginal Worker.nice. Like this it's easier tho know
> >>> where is an implementation if you know the target class.
>
>There is a fundamental difference between Nice and Java - Nice methods
>generally have no "target" class.  Sure there's sugar and preferential
>treatment given to the (potentially implicit) first parameter but
>really a class is just somewhere to store some data.
>
>I said "generally no target" because methods with only one parameter
>could be considered to be assigned to that class.
>
>Obviously a class is also associated with some set of methods but the
>class doesn't absolutely define that set.
>
> > 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 ?

......................................................................................................................
package pkg1
abstract interface LogEntry
{
String toLogString();
int severity();
}
// not default implementation provide in this project

process(LogEntry v) {
    ...
    log(v, 1);
    ...
}

.................................................................................................................
package pkg2

import pkg1;

//Make throwables print a stack trace, plus a message
class nice.lang.Throwable implements LogEntry;

toLogString(Throwable t) {
    let writer = new StringWriter();
    let printWriter = new PrintWriter(writer);
    printWriter.println("ERROR: " + t.getClass().getName() + ": " + 
t.getMessage());
    t.printStackTrace(printWriter);
    printWriter.close();
    return writer.toString();
}

severity(Throwable t) = ERROR;

.................................................................................................................
package pkg3

import pkg1;

void main(String[] args) {
    try{
       ...
    } catch(LogEntry e) {
       process(e);
    }
}

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

> >        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.

>On Thu, 7 Jul 2005, David Bernard said:
> > I don't agree see (my other reply). several class in one file is
> > practical only for little application or project with one developper.
>
> >> I liked the Java way at first, too. But later i found i have troubles
> >> creating classes, becouse i need a separate file for each class, even
> >> for minor ones. This eventually leads to "thick interfaces".
>
> > I agree with you I use a lot for "struct" (inner or not) but it's
> > difficult for co-develloper, and promote the creation of duplicate Class
> > (helper, inner struct,...) in big project where developper don't know
> > every classes (only take an overview of first level classes).
>
>Sitting next to me is a large Java code-base and I can assure you that
>one class per file isn't much protection from duplication, especially
>of helpers.
>  
>
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...)

>Maybe Nice should have one method per file? ...  Joking, joking!!!
>  
>
And have IDE like VisualAge or VisualBasic (and a combobox to select the 
method) ;-)

>Rohan
>
>  
>
David
-- 


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click