1. ZClasses OO Library contributed
- Posted by Dave Probert <zingo at purpletiger.com>
Dec 10, 2004
-
Last edited Dec 11, 2004
It's not much, but some may find it interesting/useful. All code developed by
me - even though some of it does similar things to other oop code thats out there
- I guess there are only sooo many ways of skinning a cat!!
It would be so nice to see a variant version of Euphoria that had OO concepts
built-in (ie classes and access operators, etc), but this sort of hack will have
to do for the moment :)
It should be there 'in a couple of hours'.
Feedback welcome.
. .. : :: = == == = :: : .. .
Server-Side DB driven web sites,
Software Development
and part-time games developer
contact dave_p at purpletiger dot com
. .. : :: = == == = :: : .. .
2. Re: ZClasses OO Library contributed
I disagree. I'd rather have an OO module than have it built into Eu.
3. Re: ZClasses OO Library contributed
Dave Probert wrote:
> Matt, if you can get the beasty (class, clan, group, fish, elephant or
> whatever it's
> called!) working so that we can write nice clean OO code then you are gonna
> have one
> hell of a following :) :)
I'm thinking 'euclass' may be what I use (although you can change this
to whatever you like in your version of the source, and I won't stand in
the way of any consensus that happens to develop). I'm a little leary
of using some completely new keyword, since 'class' is so familiar in
the programming world.
> I just pray that someone (RDS!?) can do either of the options so that we can
> make .exe's
> of the code. then application development can take place faster and neater
> than at
> present - IMHO.
Well, you'll be able to make exe's from my version no problem. You'll
just have to use the translated eu.ex for the back end (it seems to run
about 3 times slower on the sieve8k.exw provided in euphoria\demo\bench).
> I'm backing you all the way. I just dumped my simple Eu2.4 version of an OO
> library
> in the contributions section - but I hope that will not be needed once your
> thing is
> ready. Please, someone, start thinking how to do the pre-processor :) :) (I
> know I
> couldn't!)
Once you see the code inside the interpreter, I think it will probably
be easier to imagine. I suspect that it could be adopted to output
post-processed files rather than il code. The tricky part will be
local classes. My front end sort of does an end around on scoping rules
if a global class inherits from a local class. I suppose one solution
would be to make all methods global by default.
Hayden McKay wrote:
>
> I disagree. I'd rather have an OO module than have it built into Eu.
>
On most features, I come down on this side, too. My reason is that many
things are likely to slow down the interpreter. The cool thing about
what I've done is that it uses the interpreter as-is--only the front end
is changed, and I think the slow down is pretty small. The only problem
is that there's not an easy way to use it with the official, speedy
RDS back end.
I think I've got most of the issues ironed out. It will run the IDE
just fine. Shrouded/bound it starts up right away. I need to fix the
limited call back thing--for now I'll probably just add a bunch of
extra routines, until I can get a proper fix working that will support
an arbitrary number of call backs.
The other thing that needs to be done is to figure out how to implement
tracing. I've been thinking about writing a tracing app using wxEuphoria.
It will either be a dll/so, or a combination dll/so plus stand alone app
that will talk to the dll/so via sockets or something. I'm thinking
a standalone app, because you could have it running in the background,
and your data could persist after the main process shuts down. Also,
you could debug multiple processes at once in the same app (which might
or might not be a good thing). Either way, I suspect that I'll implement
a standard API so that others can write better debuggers than me (Pete
Lomax, where are you? :).
I also want to get a Linux version of wxEuphoria v0.4.0 out this weekend
(fortunately, the wife will be out of town, so I may have more time than
usual to spend on this).
Matt Lewis
4. Re: ZClasses OO Library contributed
On Fri, 10 Dec 2004 18:02:56 -0800, Matt Lewis
<guest at RapidEuphoria.com> wrote:
>The other thing that needs to be done is to figure out how to implement
>tracing. I've been thinking about writing a tracing app using wxEuphoria.
>It will either be a dll/so, or a combination dll/so plus stand alone app
>that will talk to the dll/so via sockets or something. I'm thinking
>a standalone app, because you could have it running in the background,
>and your data could persist after the main process shuts down. Also,
>you could debug multiple processes at once in the same app (which might
>or might not be a good thing). Either way, I suspect that I'll implement
>a standard API so that others can write better debuggers than me (Pete
>Lomax, where are you? :).
I'm here 
In execute.e, opSTARTLINE() as released only has code for trace(3) and
just needs extra code for trace(1), with all the info needed for the
trace display available in slist[a]. I just tested this and trace(1)
under eu.ex creates a ctrace.out, so this routine is already called as
and when needed.
I haven't tried calling RTLookup(), nor examined find_line(),
show_var(), or trace_back() [all in execute.e], as RL is keeping me a
tad busy these days, but between them you should be able to find all
the info and tips you need for displaying variables.
The Posetf trace works via a hardware debug register and isn't
applicable to RDS IL in any shape or form I can see.
Regards,
Pete
5. Re: ZClasses OO Library contributed
Pete Lomax wrote:
>
> On Fri, 10 Dec 2004 18:02:56 -0800, Matt Lewis
> <guest at RapidEuphoria.com> wrote:
>
> >The other thing that needs to be done is to figure out how to implement
> >tracing...Either way, I suspect that I'll implement
> >a standard API so that others can write better debuggers than me (Pete
> >Lomax, where are you? :).
>
> I'm here
> In execute.e, opSTARTLINE() as released only has code for trace(3) and
> just needs extra code for trace(1), with all the info needed for the
> trace display available in slist[a]. I just tested this and trace(1)
> under eu.ex creates a ctrace.out, so this routine is already called as
> and when needed.
>
> I haven't tried calling RTLookup(), nor examined find_line(),
> show_var(), or trace_back() [all in execute.e], as RL is keeping me a
> tad busy these days, but between them you should be able to find all
> the info and tips you need for displaying variables.
>
> The Posetf trace works via a hardware debug register and isn't
> applicable to RDS IL in any shape or form I can see.
Yeah, I invoked your name mainly because you've been fairly vocal
about custom debuggers in the past. I've looked at these things
a bit, and have an idea about implementation...just gonna take time...
Matt Lewis
6. Re: ZClasses OO Library contributed
Matt Lewis wrote:
> I also want to get a Linux version of wxEuphoria v0.4.0 out this weekend
> (fortunately, the wife will be out of town, so I may have more time than
> usual to spend on this).
Just a little marriage counseling for you... Never say "fortunately, the
wife will be out of town." Say something like, "Unfortunately, my wife
will be out of town, so I have to find something to do."
heheh. ;)
-=ck
"Programming in a state of EUPHORIA."
http://www.cklester.com/euphoria/
7. Re: ZClasses OO Library contributed
cklester wrote:
>
> Matt Lewis wrote:
>
> > I also want to get a Linux version of wxEuphoria v0.4.0 out this weekend
> > (fortunately, the wife will be out of town, so I may have more time than
> > usual to spend on this).
>
> Just a little marriage counseling for you... Never say "fortunately, the
> wife will be out of town." Say something like, "Unfortunately, my wife
> will be out of town, so I have to find something to do."
>
> heheh. ;)
LOL. Normally, I would. But she never reads this list, so I'm pretty
safe....
Matt Lewis
