I don't know what to say. Cool Beans! or...?
Mr. Muskrat gets a childish grin on his face and a gleam in his eye as he says:
Beans, beans the musical fruit; the more you eat, the more...
tye quickly silences the rodent before he can finish the rhyme.

Mr. Muskrat (having come back to his senses) asks:
Do you want to make Perl more like Java? Or were you just at a loss for a name?

Cool idea no matter what!

I must say that this looks interesting and I hope to have time to look at it more closely. I do like your idea of eventually making the style configurable as I am seeing method names being generated as "StudlyCaps" instead of "separated_with_underscores", which is generally a more Perlish thing to do (see "perldoc perlstyle").

The one thing that really interests me about this is the potential to create a "standard" style for a particular shop. It can be nothing short of frustrating to have four programmers design four completely different styles of interface for modules going into a single project. I can see this alleviating this problem and, as you pointed out, reducing the overall number of coding errors. Code generators are a Good Thing.

Code comments: a proper test suite would be a good thing. I'd recommend biting the bullet and using Test::More. It's very easy to use and you may just get hooked. I also find that much of your code spans more than 80 columns. This will make it difficult for some who would wish to collaborate to work on your code as they frequently have editors set to this width.

Refactoring is also good, but a proper test suite will make this easier. For example, in Factory.pm, your method &createAttributes has a variation of the following construct repeated six times. Surely that can be reduced.

    require PerlBean::Attribute::XXXX;
    import PerlBean::Attribute::XXXX;
    return PerlBean::Attribute::XXXX->new($opt);
[download]

I'm also wondering about the following line in your constructors:

Is there any reason for that? Typically, if someone wants to call the constructor on an existing object, it's for cloning the object, yet I don't see this facility used anywhere. Did I miss something?

Summary: This was only a few minutes of glancing through the code, so I could have missed a lot, but I think this is an interesting idea and I'd like to see more of it. Keep us posted.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Hi Ovid,

Thanks for the very constructive comments and critic.


style configurable ... as "StudlyCaps" instead of "separated_with_underscores"

With styles too, there is more than one way to do it. My sense of style is my own and I find CamelCase saves space (the underscores) -space used to be an issue when 80x24 was the way it was (maybe I'm old fashioned.) And the API isn't an iconic one that justifies short cryptic method names. Then again, I certainly don't want to impose my style. Also, I must admit I haven't read perlstyle (yet.)

I still have to figure out how to do the style precisely. Right now I think it'll be set through a PerlBean::Style object (as opposed to setting specific properties in the PerlBean and PerlBean::Attribute objects.) And yes, the default style will very likely be perlstyle as I see no reason in challenging it. That'll mean an interface change as I think a code generation tool should be written in the default style it offers itself.

My first attempts at style reconfigurability is in the PerlBean::Attribute method setMethodBase () which allows to overrule the standard camel_case to CamelCase mapping (e.g. into _camel_case which would yield to a method name set_camel_case). But I like PerlBean::Style better.


... Test::More ...

I'll have a look at that too.


... 80 columns ...

I know. It happens to me all the time. I dislike splitting strings into multiple lines. I also like to keep my conditions and loop headers on one line which clean TAB indentation. I guess I have to change to 4 space indent.


Refactoring ... Factory.pm ...

I assume you understand that the requires/imports are there to minimize the used resources by requiring and importing only the truly needed files. If I narrow down the problem to the instantiations of PerlBean::Attribute objects I don't see how to do refactoring. But don't hesitate to point me out.


I'm also wondering ... bless ($self, (ref($class) || $class));

Like you more or less pointed out yourself, it's for calling the constructor through an object instance. IMHO if you call the constructor you expect a newly constructed object and not a clone. I'd implement a clone method to clone.



Again thanks for your points and challenges. In any case they contribute to the awareness of the API, keep me alert and are a sign of good vibes.


Right now I am implementing PerlBean::Method that allows to define and document methods/interfaces. When ready this results in more consistent documentation for method inheritance/implementation/overloading.

After that I might write a PerlBean::Collection tutorial and then PerlBean::Style.

I hope my wife and kids too agree with this plan.

Cheers,
Vincenzo Zocca
Vincenzo@Zocca.no.spam.com
remove no.spam to contact me