Re: deep copy, not deep create

It seems to me that instead of manipulating data structures you should be using an object-oriented approach: A European class/package, from which the German class/package inherits its language() etc. methods.

Inheritance will take care of your 'overriding' requirements.

To mock around with these concepts, use Class::Prototyped:

   use Class::Prototyped;

   my $european = Class::Prototyped->new(
       language => 'English',
       food     => 'Europizza',
   );

   my $german = Class::Prototyped->new(
       'parent*' => $european,
       food      => 'Wiener Schnitzel',
   );

   my $bavarian = Class::Prototyped->new(
       'parent*' => $german,
   );

   print "Default language: ",
         $bavarian->language(), "\n";

   $bavarian->language("Bavarian");
   print "Explicitely set language: ",
         $bavarian->language(), "\n";

    print "Default food: ",
          $bavarian->food(), "\n";
[download]

Comment on Re: deep copy, not deep create Select or Download Code

Replies are listed 'Best First'.
Re: Re: deep copy, not deep create by ryantate (Friar) on May 27, 2004 at 18:18 UTC
I've only just started using OOP, but isn't the issue of attribute storage structure completely orthogonal to whether the interface is procedural or object oriented? I mean, even if the data happens to be stored in an object, the programmer still has to worry about how it is stored, still has to bless some sort of data structure into object-dom, and if object attributes are stored internally as a hash, as is usually the case, this issue will still come up. You mention inheritence, but inheritence affects only how methods are invoked and which methods are invoked, right? Again, it would seem methods are orthogonal to data. Your response does sort-of address the issue by implying that the data structure should be flattened and any desired hierarchy managed by methods rather than the actual data structure, but you never come out and say that. You also talk about "an object oriented approach" and "manipulating data structures" as though they are two different things. Given that someone has to design the object oriented data representation in the first place, I wonder what you mean. Just curious. I honestly don't see how OOP applies here. Respectfully, RT	[reply]

Replies are listed 'Best First'.

Re: Re: deep copy, not deep create
by ryantate (Friar) on May 27, 2004 at 18:18 UTC

I've only just started using OOP, but isn't the issue of attribute storage structure completely orthogonal to whether the interface is procedural or object oriented? I mean, even if the data happens to be stored in an object, the programmer still has to worry about how it is stored, still has to bless *some* sort of data structure into object-dom, and if object attributes are stored internally as a hash, as is usually the case, this issue will still come up.

You mention inheritence, but inheritence affects only how methods are invoked and which methods are invoked, right? Again, it would seem methods are orthogonal to data.

Your response does sort-of address the issue by implying that the data structure should be flattened and any desired hierarchy managed by methods rather than the actual data structure, but you never come out and say that.

You also talk about "an object oriented approach" and "manipulating data structures" as though they are two different things. Given that *someone* has to design the object oriented data representation in the first place, I wonder what you mean.

Just curious. I honestly don't see how OOP applies here.

Respectfully,
RT

[reply]