digitalmars.D - What about some standard interfaces in phobos?

J Anderson (10/10) Jun 07 2004 Java has some standard interfaces such as clone and serialize. Parhaps

Arcane Jill (13/23) Jun 07 2004 Someone told me a few weeks ago that dup always implies a deep copy.

J Anderson (28/64) Jun 07 2004 In that case the user could re-implement the serialization interface. ie...

Ivan Senji (12/89) Jun 07 2004 Trouble is,

J Anderson (20/54) Jun 07 2004 Well I was just using stubs. Of course you could re-use the dup from A

Norbert Nemec (18/26) Jun 07 2004 The idea in general is good. The example seems rather worthless to me: W...

J Anderson (17/47) Jun 07 2004 Dam, I thought that it worked for interfaces. Apparently it only works
J Anderson (5/12) Jun 07 2004 You wouldn't need RTTI when your using polymorphism for things like

J Anderson <REMOVEanderson badmama.com.au> writes:

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/

Jun 07 2004

Arcane Jill <Arcane_member pathlink.com> writes:

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

Jun 07 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

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/

Jun 07 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"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/

Jun 07 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

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/

Jun 07 2004

Norbert Nemec <Norbert.Nemec gmx.de> writes:

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

Jun 07 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

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/

Jun 07 2004

J Anderson <REMOVEanderson badmama.com.au> writes:

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/

Jun 07 2004

D Programming

C/C++ Programming

Other

digitalmars.D - What about some standard interfaces in phobos?