normal objects?

mkmcconn has asked for the wisdom of the Perl Monks concerning the following question:

I hope this is the right place to post this.

As new as I am to Perl, I am almost as new to databases. But, two ideas that I picked up from working with a database were 1) the "normal form", and 2) the "primary key". As I began to absorb these concepts, the light began to dawn for me, how a database can be used to describe many different views of the same thing, if the designer has been careful to distinguish one thing from another: called "normal form". This enabled me to design queries which produce the various views that are usually requested from a database.

Any of the aspects of the data in multiple rows of a normal form table can be abstracted out for reference in a new relationship, by using the idea of a primary key. I can join the data of two tables together, selecting only the parts that I want to see. This new selection itself can (and should) be "normal form", describing a unique entity on each line and therefore, in turn, adaptable to other uses by applying a primary key to each line of the product of an ad-hoc query.

Now I've come to Perl and my question - actually, to Perl only in a general sense, as a programming language that is adaptable to the "object-oriented" paradigm. I had the idea that in the programming paradigm called "object- oriented", there must be something like a relational database's ability to create various views of an object - "Bessie" viewed as "ground beef". I would expect multiple views to be such that "Bessie" can be followed from calf to cow (one instance of cow becoming another kind of cow), to patties(a cow with all of its cow-methods removed), still identifiable through all these changes, as a specific instance of "cow". But in the end, Bessie now "tastes yummy" and the "speak" and "eat" method is an irrecoverably inapplicable or radically redefined attribute.

It is often the case that a real world object, while retaining some key element of identity, is of interest because it is being made into something else. As the process matures, the beefness of Bessie becomes more important than her cowness. But, it seems to me that a programming object is simply a "cow" or it is not. A "Cow::" cannot become "Beef::" without losing its identity entirely: however, in the real world very many "cows" become "beef". It seems that there is more certainty built into a programming object, than a real-world object. Consequently, there is a limitation built in to how exactly this paradigm can map to the real world.

Brethren, I apologize for how impractical this question is. Maybe I'm missing something really obvious, and 'thinking sophomorically'. But, I'm looking for every handle I can find, so that programming will make more sense to me - and here is a handle that I thought would be there, but seems to be missing. How wrong am I?

mkmcconn

Comment on normal objects?

Replies are listed 'Best First'.
Re: normal objects? by tadman (Prior) on Jan 25, 2001 at 00:37 UTC
This Perl not compatible with vegetarians: `package Cow; sub new { my ($this) = shift; my ($class) = ref($this) \|\| $this; my ($meat) = {}; bless ($meat, $class); return $meat; } sub grind { my ($meat) = shift; bless ($meat, "Beef"); return $meat; } package main; my ($bessie) = new Cow(); grind $bessie;` [download] Certainly you could define a base class for both Cow and Beef which would have methods that both would use (via the @ISA method in the package) so that regardless of the condition of the "$bessie", it is still a member of the base class, even after "grind()". Where other languages can only "cast" types up the class chain, Perl can make lateral moves, or even a move to left field, as you can re-bless() something at will. Presto! In your application, I suspect the contents of the object might have to be modified by the conversion method (i.e. grind()) before being re-bless()ed so that the data is compatible with the new methods that it will use.	[reply] [d/l]
Re: Re: normal objects? by mkmcconn (Chaplain) on Jan 25, 2001 at 01:14 UTC
tadman, the part you describe is easier than I thought it would be. But (pardon me for thinking out loud - I promise to read the docs) what if $bessie has the $bessie->eat method, prior to re-blessing and a new $bessie->eat method after the conversion by grind()? Am I confusing myself, or, won't there be a conflict? mkmcconn	[reply]
(jeffa) 3Re: normal objects? by jeffa (Bishop) on Jan 25, 2001 at 01:23 UTC
Yes there will be a conflict. You will need this as well: `package Beef; use vars qw(@ISA); #if you use strict @ISA = qw(Cow);` [download] Which is why it's wise to plan out your inheritance tree before you start coding. OOP is only as good as its design. To be technical, Beef IS NOT a Cow - a Cow HAS Beef. Take a look into aggregation for alternatives to inheritance. Jeff L-LL-L--L-LL-L--L-LL-L-- -R--R-RR-R--R-RR-R--R-RR F--F--F--F--F--F--F--F-- (the triplet paradiddle)	[reply] [d/l]
Re: normal objects? by MeowChow (Vicar) on Jan 25, 2001 at 01:20 UTC
If you think of your database tables as object classes, with their columns being object attributes, and with rows being object instances, you can always achieve the equivalance of database views by programmatically manipulating your objects. Such code is commonly implemented as object methods. Remember that views are simply arbitrary representations of your underlying data, not entities in themselves.	[reply]
Re: normal objects? by clemburg (Curate) on Jan 25, 2001 at 15:31 UTC
An Introduction to Database Systems by C. J. Date has a very good section on the comparison of the OO model and the relational model. You might be interested in that. Christian Lemburg Brainbench MVP for Perl http://www.brainbench.com	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks