Java has some standard interfaces such as clone and serialize.  Parhaps phobos could have the same to help standardise things.  For example:

interface Duplicate
{
   Duplicate dup(); //Shallow
   Duplicate fulldup(); //Deep
}

I'll let the group argue the specifics.

-- 
-Anderson: http://badmama.com.au/~anderson/

In article <ca17h4$21pl$1@digitaldaemon.com>, J Anderson says...
>
>Java has some standard interfaces such as clone and serialize.  Parhaps phobos could have the same to help standardise things.  For example:
>
>interface Duplicate
>{
>    Duplicate dup(); //Shallow
>    Duplicate fulldup(); //Deep
>}
>
>I'll let the group argue the specifics.

Someone told me a few weeks ago that dup always implies a deep copy.

But I like the idea of standard interfaces. Particularly serialize. Trouble is, it's a really, really difficult thing to get right, and Java, IMO, hasn't.

Example: someone implements

>       class A : Serialize

with full functionality. Then along comes someone else who subclasses A:

>       class B : A

but who FORGETS to implement serialization functionality (or can't be bothered, or thinks "I'll get round to it next week", or doesn't realize it's important. Result? b.serialize() will only serialize the superclass.

It's a thorny issue. I'm all in favor of serialization, but interfaces may not be the best tool for that job. Ideally, I'd like a language-mechanism whereby ALL objects could be serialized by some built-in D magic.

Arcane Jill

Arcane Jill wrote:

>In article <ca17h4$21pl$1@digitaldaemon.com>, J Anderson says...
>  
>
>>Java has some standard interfaces such as clone and serialize.  Parhaps phobos could have the same to help standardise things.  For example:
>>
>>interface Duplicate
>>{
>>   Duplicate dup(); //Shallow
>>   Duplicate fulldup(); //Deep
>>}
>>
>>I'll let the group argue the specifics.
>>    
>>
>
>Someone told me a few weeks ago that dup always implies a deep copy.
>
>  
>
Fair enough.

>But I like the idea of standard interfaces. Particularly serialize. Trouble is,
>it's a really, really difficult thing to get right, and Java, IMO, hasn't.
>
>Example: someone implements
>
>  
>
>>      class A : Serialize
>>    
>>
>
>with full functionality. Then along comes someone else who subclasses A:
>
>  
>
>>      class B : A
>>    
>>
>
>but who FORGETS to implement serialization functionality (or can't be bothered,
>or thinks "I'll get round to it next week", or doesn't realize it's important.
>Result? b.serialize() will only serialize the superclass.
>
>  
>
In that case the user could re-implement the serialization interface. ie:

interface Duplicate
{
   Duplicate dup();
     Duplicate lightdup();
}


class A : Duplicate
{    Duplicate dup() { return null; }
   Duplicate lightdup() {  return null; }   }

class B : A, Duplicate
{    Duplicate dup() { return null; }
   Duplicate lightdup() {  return null; }       }

But it would be nice if you could force particular functions to be re-implemented at every level.  I requested for that before.

>It's a thorny issue. I'm all in favor of serialization, but interfaces may not
>be the best tool for that job. Ideally, I'd like a language-mechanism whereby
>ALL objects could be serialized by some built-in D magic.
>  
>
Yeah I would like that as well.  I think that will come in when properties can be detected by RTTI.  However I should point out that interfaces could still be used in that solution.  If a user wanted to do it manually then they would simply include the interface, not the automatic class.

-- 
-Anderson: http://badmama.com.au/~anderson/

"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:ca193n$23tp$1@digitaldaemon.com...
> Arcane Jill wrote:
>
> >In article <ca17h4$21pl$1@digitaldaemon.com>, J Anderson says...
> >
> >
> >>Java has some standard interfaces such as clone and serialize.  Parhaps phobos could have the same to help standardise things.  For example:
> >>
> >>interface Duplicate
> >>{
> >>   Duplicate dup(); //Shallow
> >>   Duplicate fulldup(); //Deep
> >>}
> >>
> >>I'll let the group argue the specifics.
> >>
> >>
> >
> >Someone told me a few weeks ago that dup always implies a deep copy.
> >
> >
> >
> Fair enough.
>
> >But I like the idea of standard interfaces. Particularly serialize.
Trouble is,
> >it's a really, really difficult thing to get right, and Java, IMO,
hasn't.
> >
> >Example: someone implements
> >
> >
> >
> >>      class A : Serialize
> >>
> >>
> >
> >with full functionality. Then along comes someone else who subclasses A:
> >
> >
> >
> >>      class B : A
> >>
> >>
> >
> >but who FORGETS to implement serialization functionality (or can't be
bothered,
> >or thinks "I'll get round to it next week", or doesn't realize it's
important.
> >Result? b.serialize() will only serialize the superclass.
> >
> >
> >
> In that case the user could re-implement the serialization interface. ie:
>
> interface Duplicate
> {
>     Duplicate dup();
>
>     Duplicate lightdup();
> }
>
>
> class A : Duplicate
> {
>     Duplicate dup() { return null; }
>     Duplicate lightdup() {  return null; }
> }
>
> class B : A, Duplicate
> {
>     Duplicate dup() { return null; }
>     Duplicate lightdup() {  return null; }
> }
>
> But it would be nice if you could force particular functions to be re-implemented at every level.  I requested for that before.

What do you mean by this? In your examples
dup and lightdup are forced do be reimplemented when
you implement Duplicate, versions from A aren't used,
and you are forced do write them again. Is this what you need?

>
> >It's a thorny issue. I'm all in favor of serialization, but interfaces
may not
> >be the best tool for that job. Ideally, I'd like a language-mechanism
whereby
> >ALL objects could be serialized by some built-in D magic.
> >
> >
> Yeah I would like that as well.  I think that will come in when properties can be detected by RTTI.  However I should point out that interfaces could still be used in that solution.  If a user wanted to do it manually then they would simply include the interface, not the automatic class.
>
> --
> -Anderson: http://badmama.com.au/~anderson/

Ivan Senji wrote:

>"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message
>news:ca193n$23tp$1@digitaldaemon.com...
>  
>
>>In that case the user could re-implement the serialization interface. ie:
>>
>>interface Duplicate
>>{
>>    Duplicate dup();
>>
>>    Duplicate lightdup();
>>}
>>
>>
>>class A : Duplicate
>>{
>>    Duplicate dup() { return null; }
>>    Duplicate lightdup() {  return null; }
>>}
>>
>>class B : A, Duplicate
>>{
>>    Duplicate dup() { return null; }
>>    Duplicate lightdup() {  return null; }
>>}
>>
>>But it would be nice if you could force particular functions to be
>>re-implemented at every level.  I requested for that before.
>>    
>>
>
>What do you mean by this? In your examples
>dup and lightdup are forced do be reimplemented when
>you implement Duplicate, versions from A aren't used,
>and you are forced do write them again. Is this what you need?
>
>  
>
Well I was just using stubs.  Of course you could re-use the dup from A in B and append any new data to that.

interface Duplicate
{
  Duplicate dup();

  Duplicate lightdup();
}


class A : Duplicate
{
  Duplicate dup() { ... }
  Duplicate lightdup() {  ... }
}

class B : A, Duplicate
{
  Duplicate dup() { ... super.dup(); ... }
  Duplicate lightdup() { ... super.lightdup(); ...}
}


-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Java has some standard interfaces such as clone and serialize.  Parhaps phobos could have the same to help standardise things.  For example:
> 
> interface Duplicate
> {
>     Duplicate dup(); //Shallow
>     Duplicate fulldup(); //Deep
> }

The idea in general is good. The example seems rather worthless to me: Where would you use the interface Duplicate? If you have a variable of type Duplicate, you will always only be able to create copies from it, but these copies will have the compile-time type Duplicate as well. Afterwards, you will need RTTI to cast the copy to the type of the original which seems rather inelegant to me.

The interface might be useful if template parameters could be restricted, but currently, this is not possible.

Furthermore, I don't know whether the following would work at all:

-----------
class MyClass: Duplicate {
        MyClass dup() { ... }
}
-----------

I assume, this will fail because "MyClass dup()" does not fit for the
requested "Duplicate dup()". (In any case, the specs are not very specific
about it.)

Norbert Nemec wrote:

>J Anderson wrote:
>
>  
>
>>Java has some standard interfaces such as clone and serialize.  Parhaps
>>phobos could have the same to help standardise things.  For example:
>>
>>interface Duplicate
>>{
>>    Duplicate dup(); //Shallow
>>    Duplicate fulldup(); //Deep
>>}
>>    
>>
>
>The idea in general is good. The example seems rather worthless to me: Where
>would you use the interface Duplicate? If you have a variable of type
>Duplicate, you will always only be able to create copies from it, but these
>copies will have the compile-time type Duplicate as well. Afterwards, you
>will need RTTI to cast the copy to the type of the original which seems
>rather inelegant to me.
>
>The interface might be useful if template parameters could be restricted,
>but currently, this is not possible.
>
>Furthermore, I don't know whether the following would work at all:
>
>-----------
>class MyClass: Duplicate {
>        MyClass dup() { ... }
>}
>-----------
>
>I assume, this will fail because "MyClass dup()" does not fit for the
>requested "Duplicate dup()". (In any case, the specs are not very specific
>about it.)
>  
>
Dam, I thought that it worked for interfaces.  Apparently it only works for abstract types:

//Works

abstract class Duplicate
{
   Duplicate dup();
     Duplicate fulldup();
}



class A : Duplicate
{    A dup() { return null; }
   A fulldup() {  return null; }   }


-- 
-Anderson: http://badmama.com.au/~anderson/

Norbert Nemec wrote:

>
>The idea in general is good. The example seems rather worthless to me: Where would you use the interface Duplicate? If you have a variable of type Duplicate, you will always only be able to create copies from it, but these copies will have the compile-time type Duplicate as well. Afterwards, you will need RTTI to cast the copy to the type of the original which seems rather inelegant to me.
> 
>

You wouldn't need RTTI when your using polymorphism for things like containers.


-- 
-Anderson: http://badmama.com.au/~anderson/