Re: Smalltalk-like browser for perl

[dave0]

Being an ex-Smalltalk programmer, I've been thinking about something like this for quite some time. It's definitely a good idea, and you're off to a great start.

One question, though, is there any particular reason you created your new syntax:

PACKAGE:
Goe::Browser

INHERIT:
Goe::Object

USES:
Goe::Browser::UI Goe::Browser::Events

METHOD initialize

instead of using standard Perl like so:

package Goe::Browser;

use base qw(Goe::Object);
use Goe::Browser::UI;
use Goe::Browser::Events;

sub initialize

Or, is being able to handle standard Perl package/subroutine syntax up-and-coming in the next version? =)

[awwaiid]

Not really, the main reason was because it was easier :)

Well... it does keep the files neater. I think that I would prefer making an import mechanism. Most things that are filed-in probably aren't already in nice little packages.

Then again, the way I have it is still sort of there so that I can see the source code. In theory they should all be stored in a more-binary like image file(s). For instance, someone putting "END METHOD" in their method would be bad :)

The main reason I haven't done this yet is because I just barely got it bootstrapped, and until now have actually been editing those .goe files by hand.

[dave0]

Well... it does keep the files neater. I think that I would prefer making an import mechanism. Most things that are filed-in probably aren't already in nice little packages.

Hmmm... import/export would work, but if there's no real reason to use END METHOD and the like (there seems to be a direct perl equvalent for each of your new keywords) it might make more sense to do away with the .goe format and just spit Perl out the back end. This would make the edit-test-edit cycle a bit easier, as you wouldn't have to convert .goe to pure Perl before doing anything with it outside the browser.

Then again, the way I have it is still sort of there so that I can see the source code. In theory they should all be stored in a more-binary like image file(s).

Would a Smalltalk-style binary image really provide any benefit here?

For instance, someone putting "END METHOD" in their method would be bad :)

If the need is there for special delimiters, one possibility would be to place them in a comment line. Something like:

#*# END METHOD

might work particularly well, as you can check for the special #*# comment characters as well as the specific tag, reducing the chance of false hits. Plus it's fairly nonintrusive, so you might be able to convince a module maintainer to accept patches that make their CPAN module compatible with your browser. =)

[awwaiid]

What is really needed is a perl parser (preferably in perl). There are the B:: modules, but they don't quite do what I want. I started tackling one a while back, but got distracted quite quickly. Idealy I want something that takes perl and cuts it into a parse tree at least at the sub (method) level, preserving all whitespace (at least within subs).

You're right though, there is no reason really to make it into a more binary-like scheme, except for maybe load-time (which considering all the interpreting going on doesn't seem like a problem at this point, and could easily be changed later).

As for an actual pragmatic use of this thing, I would definately need a clean way of allowing CPAN and other modules / scripts to be integrated into the environment. I would either have to (at least partially) give up the full-OO feel, or just use them as external references. Now that I'm thinking about it, using them as external references is a much better idea (though some of the OO could still be given up I suppose).

My mind swims with all the thoughts and ideas involved in creating a wonderful programming environment around the basic concept of making it smalltalk-like :)

Damn I love Perl.