Speed can't be that relevant, CGI doesn't do any syntax validation, so the same generic function could be installed at import time for all html-tags, maybe with a closed over $tag_name if necessary.

What am I missing?

¹) didn't know it's possible to predeclare an AUTOLOADed sub ... (scratch)

update

interesting...

  DB<181> package Test; sub AUTOLOAD { $AUTOLOAD,\@_ }

  DB<182> bar(1,2,3)
Undefined subroutine &main::bar called at (eval 196)[multi_perl5db.pl:
+644] line 2.

  DB<183> Test::bar(1,2,3)
 => ("Test::bar", [1, 2, 3])

  DB<184> *bar=\&Test::bar
 
  DB<185> bar(1,2,3)
 => ("Test::bar", [1, 2, 3])
[download]

but

  DB<186> *foo=*Test::foo
 
  DB<187> foo(1,2,3)
Undefined subroutine &Test::foo called at (eval 206)[multi_perl5db.pl:
+644] line 2.
[download]

> Not sure why AUTOLOAD is needed in CGI anyway, the allowed HTML-tags seem to be exported from CGI to the local namespace, but only spring into existence within the stash of %CGI:: after first use! Speed can't be that relevant, CGI doesn't do any syntax validation, so the same generic function could be installed at import time for all html-tags, maybe with a closed over $tag_name if necessary.

I believe the original reason was to defer the compilation so the majority of functions, not just html functions, were wrapped in quotes and then eval'd and added to the namespace when called. Or you could pass -compile (or call ->compile) to force them to compile at import time. It was kind of a way to fix the God object problem when compiling a 4000+ line module was slow. An added side effect was the ability to call CGI with arbitrary tags not included in the module... it was future proofed! You could call CGI->wibble and get a <wibble> tag.

Anyway it's all gone now, or soon will be.

Hi

I wasn't criticizing CGI but trying to analyze the conditions for a new HTML DSL module. :)

I'm sure compilation speed shouldn't matter when generating closures. (I will add a benchmark later this day)

But CGI was designed for Perl 4 and I suppose Perl 4 wasn't able to closure... IIRC it didn't even have lexical variables.

Your wibble-tag is implemented as a method call, so it wouldn't depend on exporting and pre declaration anyway.

But DSLs are at the very least just syntactic sugar to avoid method calls.

> Anyway it's all gone now, or soon will be

Thanks for your work! :)

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

PS: Je suis Charlie!

> it was future proofed! You could call CGI->wibble and get a <wibble> tag.

I wasn't able to reproduce this without explicitly importing "wibble"

  DB<100> use CGI qw(:all wibble)

  DB<101> wibble
 => "<wibble />"
[download]

but

  DB<100> use CGI ':all'

  DB<101> $x=CGI->new()

  DB<102> $x->wibble()
Undefined subroutine CGI::wibble
 at (eval 24)[multi_perl5db.pl:644] line 2
[download]

So autoloading makes not much sense in this case.

It doesn't make the code more flexible it only delays the installation, which could already happen in the importer.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)}

PS: Je suis Charlie!