Re: Too lazy for constructors

Have you seen Class::Contract? I'd say that this does no more for sloppiness than that does. And actually, I'm unsure of why I should use this over that. (I'm not being snooty here, I'm honestly working my way through the Class:: heirarchy and trying to see the advantages of the different approaches.) You've got finer-grained types (int, string, real, etc.) and Tangram schema importation. Class::Contract doesn't have those features, but has a lot of other ones; could it be extended, using it as a base class (i.e. Class::Contract::Tangram?)

I guess I'm wondering if this is something one would only use if they're using Tangram (which I don't know about), and whether it would suffice to extend an existing approach/module from Class:: (e.g. Accessor, Struct, etc.) rather than create a new one.

Also, if you CPAN this, I'd suggest a different name than Tao::Object; something like Tangram::Schema or Class::Tangram would seem to be a better fit.

-- Frag.

Comment on Re: Too lazy for constructors

Replies are listed 'Best First'.
Re: Re: Too lazy for constructors by mugwumpjism (Hermit) on Jul 18, 2001 at 20:07 UTC
You're a star, this is pretty close to what I'm after. There are reasons why I am using Tangram over, say, Class::DBI: Support for Polymorphism in data types Support for non-trivial relationships between classes (sets, arrays, etc) Objects that contain/refer to other objects are automatically loaded as needed via a tied variable Queries are in Perl, not SQL. This is achieved with a very clever trick - having a variable type that represents a "remote" (that is, not local) object, and overloading functions on that so you can do, eg `$db->select($remote_orange, $remote_orange->{field} eq "value");`. This returns a data structure that can be converted by the object data persistence engine to a SQL query. What I think is the direction from here is to refine Class::Contract to the point where it is suitable for generating storage schemas; be they Tangram or Class::DBI or Alzabo or whatever. "Scalar" is, by definition, of boundless length, which isn't too useful if you want to store it in a column of a relational database. Thanks for the pointer, I guess I'll take up this conversation with the Class::* maintainers. The POOP list, which seemed the natural place for this, seemed worryingly quiet. `srand 3.14159; print join("", sort{rand 1<0.5}map{$_^"\037"}split m{ }x,"qmptk\|z~wOzm??l]pUqx^k?j"),",\n";` [download]	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Too lazy for constructors
by mugwumpjism (Hermit) on Jul 18, 2001 at 20:07 UTC

You're a star, this is pretty close to what I'm after.

There are reasons why I am using Tangram over, say, Class::DBI:

Support for Polymorphism in data types
Support for non-trivial relationships between classes (sets, arrays, etc)
Objects that contain/refer to other objects are automatically loaded as needed via a tied variable
Queries are in Perl, not SQL. This is achieved with a very clever trick - having a variable type that represents a "remote" (that is, not local) object, and overloading functions on that so you can do, eg $db->select($remote_orange, $remote_orange->{field} eq "value");. This returns a data structure that can be converted by the object data persistence engine to a SQL query.

What I think is the direction from here is to refine Class::Contract to the point where it is suitable for generating storage schemas; be they Tangram or Class::DBI or Alzabo or whatever. "Scalar" is, by definition, of boundless length, which isn't too useful if you want to store it in a column of a relational database.

Thanks for the pointer, I guess I'll take up this conversation with the Class::* maintainers. The POOP list, which seemed the natural place for this, seemed worryingly quiet.

srand 3.14159; print join("",
sort{rand 1<0.5}map{$_^"\037"}split m{
}x,"qmptk|z~wOzm??l]pUqx^k?j"),",\n";
[download]

[reply]
[d/l]
[select]