On Thursday 03 June 2004 14:00, you wrote:
> > outside a class, kinda javascript.
>
> Basically, no. You can create static methods that can be called from a
> class without instantiating an object:
>...
That was my understanding too (specially after digging into my Java book
(yes I have just one and it's called Java for C++ programmers :-) ).
Here is a fun idea. Let's make an Inline::Javascript. Hmm I mean Why don't
_you_ do a I::Jscript :-)
Seriously, I can of course do that myself and I may because I think it's
fun. The trick in this case is to use Inline::Java to implement
Inline::Javascript
I was thinking of something like this:
use Inline JavaScript => <<EOJS ;
static function1(){}
static function2(){}
EOJS
which would behind the sceen become
use Inline Java => <<EOJS ;
class Javascript_something unreadable1231238757574
{
static function1(){}
static function2(){}
}
EOJS
followed by:
sub function1 {Javascript_something unreadable1231238757574.function1(@_);}
sub function2 {Javascript_something unreadable1231238757574.function2(@_);}
I let argument typing torment you. (hmm but you must have fixed that
already)
OK this is the first part, getting syntactic sugar for not using a class
(bear with me for a few seconds more). is it possible to declare a class
static to make all it's members static? thus eliminating the static in the
function declaration.
The second part is to run some java code let's call this a javascript::Run
(ugly name but I'm too tired to argue with my own self)
use inline Javascript::Run => <EOJSR ;
function1() ;
function1() ;
....
EOJSR
which would translate to
use inline Java => <EOJSR ;
class Javascript_something unreadable_too_123
{
static JavaScript_Run
{
function1() ;
function1() ;
....
}
}
EOJSR
followed by a:
Javascript_something unreadable_too_123.JavaScript_Run() ;
Isn't that cool? language de-objectifying, the opposit of what the rest of
the world wants to do.
With a parser, we could throw both constructs in one ILSM.
Ok, an explaination of why I want to do this crazy stuff might be
appropriate now. I wrote a build system and it's rather good. I choose
_not_ to have an object oriented interface to make it easy to write
"makefiles". Here is an example:
if(GetConfig('EXTRA_OBJECT_FILES'))
{
AddRule('extra_object_file', ['*.lib' => 'd']) ;
AddRule('d', ['d'], "some_command") ;
}
AddRule 'dep1', ['a' => 'a.dep'], "a_second_command" ;
AddRule 'dep2', ['b' => 'a.dep'], "another_command" ;
The above is actualy kind of object oriented but without the syntax. I push
the source code above in a specific package then I let the 'AddRule' sub
find out from wich package it was called. After 1 and half year working on
the build system, I am starting to see some minor disadvantages but it has
served very well to this point.
Hmm, I made a little mistake in the examples above. I pushed the functions
in a unique Java class when I could use your new system and push them in
the current package instead. Now with our pseudo Javascript I could write
something like:
>>>>>>>>>>>>>>>
Use PBS::Java ;
# this above is for the build system to differenciate java code from perl
# code. when the build system find "PBS::Java" it will wrap the whole
#script in "use Inline Javascript => ....." so the user doesn't have
# to do it
# it would also push some "import" to give access to the build system
# (through perl) from java.
# the code bellow looks like perl code because I am too lazy and
# ignorant of java syntax to write it but the principle is the same
# if a perl construct doesn't exist in java, the "imported" functions
# could do the mapping before calling perl (there are few functions)
# bellow should be javaified
if(GetConfig('EXTRA_OBJECT_FILES'))
{
AddRule('extra_object_file', ['*.lib' => 'd']) ;
AddRule('d', ['d'], "some_command") ;
}
AddRule 'dep1', ['a' => 'a.dep'], "a_second_command" ;
AddRule 'dep2', ['b' => 'a.dep'], "another_command" ;
<<<<<<<<<<<<<<<<<<<<
Now I have a build system written in perl that I script in Java!
Shoot, I'm ready.
Cheers, Nadim.
