perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Gunton <>
Subject Re: Some philosophical questions
Date Mon, 01 Aug 2005 19:32:43 GMT
Gerald Richter wrote:
>>If you need any help with English documentation cleanup then 
>>let me know which files and I'll have a crack at it.
> Thanks for your offer. The main thing I like to do, to check that the old
> stuff that is only valid for 1.3 (like optRawInput etc.) is replaced by the
> new ones. After this is done, I am happy if you check my english

Sure, just let me know when you are ready, the offer is open.

> P.S. If you feel you have some free time, the most important thing for
> advocacy of Embperl (other them makeing 2.0 ready), is to update
> Embperl 
> And add all the new Embperl::Object and other 2.0 stuff into it...

I don't feel qualified (yet) to write too much about Embperl 2.0, since I don't currently
use it 
(except for testing the bugs which are currently in play) and I truthfully haven't investigated
new features too much (e.g. recipes, providers or the new objects).

On a side note, I find some of the new stuff in 2.0 a little obscure. As an application programmer
can well appreciate the ability to deconstruct the request to the extent that 2.0 appears
to allow, 
but I honestly cannot see how or why I would personally want to do any of that. Perhaps more

concrete examples of where these new features come in useful would be helpful, both to people
me and newcomers thinking about using Embperl.

On a philosophical note, I have discovered from personal experience that new ideas are not

necessarily self-evident to other people, they need prompting and examples to bring it all
to life 
so they can see how it applies to their own situation. There is an "Aha!" moment you're looking
here, where programmers look at this and see in a flash how it will make their lives easier.

Currently, all I really want out of Embperl is the ability to a) embed Perl code in the HTML

templates, and b) structure my website in a vaguely object-oriented manner through the inheritance

that EmbperlObject (or Embperl::Object) provides. All that is currently satisfactorily supplied
Embperl 1.x. So to me, the only current perceived benefit of moving to Embperl 2.x is the

performance increase, and this is certainly outweighed by the lingering bugs and continuing

almost-but-not-quite compatibility with 1.x. I'll continue to test my codeset under 2.x, but
I am 
fearful of putting it up live on the production server because it's almost impossible for
me to test 
every little case - it's a lot of code (over 50,000 lines in crazyguyonabike) and there's
a lot of 
community input, which I don't want to risk breaking.

On the new feature front - Why exactly would I write a new recipe or rearrange the providers?
doubt there are good examples, if someone would be good enough to provide these then they
could form 
some of the foundation for the Cookbook.

I decided to take another look at the README.v2 and correct the English grammar/spelling issues
I could find. I am attaching this for you to look at, I hope it's useful as a start.

I will investigate, as time allows, the different Wiki toolkits that are available out there
and see 
if there is anything that looks like being a good fit here. I agree that perhaps making this
a Wiki 
would be more scalable that having one person write a document, though I do still like the

"ownership" and consistency of style that can come from a document written by a single person
than committee. Committees come up with something that attempts to please everybody but often
up being uninspired and bland.



View raw message