Re: [Oopic-compiler-devel] Testing...

[Neil D. <nd...@us...>]

Andrew Porrett wrote:
> >There may be some things we can fudge - for example most C programmers
> >don't *need* local variables to be implemented using a stack.  We could
> >make them global, with some name mangling to ensure uniqueness, and give
> >them the semantic appearence of local scope, including variables of the
> >same name in nested blocks etc.
> 
> You have to be careful with auto variables.  If you silently make them
> static, you'll run out of RAM real fast.  Looks like we may be stuck doing
> this anyway.  I doubt that the interpreter can deal with data at a variable
> address.

Fair point.

Has anyone suggested implementing malloc to work in EEPROM, and providing
pointer arithmetic?

> >> Do we need structures and unions, for example?
> >
> >Yeah, there's probably not much desire for this kind of thing, but we could
> >have such features as long-term wish-list items, to be implemented if and
> >when required.
> 
> I guess I could see a need for unions - "I need a word variable here, but
> there's no more RAM.  If only I could reuse those two bytes..."

Certainly true.  Maybe not essential to implement it as a high priority
though.

> I have no problem with BASIC, but I wonder how many BASIC users would try
> our approach.  Obviously, there will be some, as they'd want to get around
> some of the compiler bugs (array sizes, broken nested switch constructs, ...)

To my knowledge there isn't any one defacto standard BASIC, and so we would
have less incentive to do much to the existing OOPic BASIC support, beyond
fixing the obvious bugs and some other tweaks.  So I imagine it wouldn't be
as much work as implementing comprehensive C support.

> >> Are we going to ask the community what they'd like to see?
> >
> >Sounds like a good idea.  Would you like to post something?
> 
> Doh!  I'm not the diplomatic one.  I also think it's a bit early for that.
> I thought we'd come up with our overall feature plan and present it for
> review.

Fair points!  I imagine our overall feature plan is going to look really
ambitious, and will either spark enthusiasm or cries of, "You'll never
manage it!".  But it should also get people commenting on our ideas and
maybe suggesting stuff we hadn't considered.  However I bet most people
will just glaze over because it's mostly C stuff....

Speaking of a feature plan, maybe we should actually start making one, just
as a plain text file, and add it to the Sourceforge page as documentation.
I guess we need to read up on how to do updates to files and give ourselves
modify rights etc.

Sourceforge is set up to use CVS for version control for source and docs.
Have either of you use CVS much/at all?

  [my OOP suggestion snipped for brevity]

> I think that it's not C anymore, but I don't have a huge problem with that.

But then neither is oUserClass (or any of the OOPic object for that
matter!).  The idea is to make the current oUserClass functionality a bit
more like an existing standard OOP language, and to allow the created
objects to have a type, rather than all user classes being of type
oUserClass regardless of what user class they actually are!

> My immediate thoughts are:
> - where does this thing get constructed?  RAM?  EEPROM?

Exactly the same as existing oUserClass variables, which is presumably RAM.

> - when does it get constructed?  If it's only at program startup, the "new"
> seems like a fib.

It's no more of a fib than the existing 'new' when creating OOPic objects.
Were you thinking about removing 'new' and making OOPic object creation
look more like global statics?

> - can this thing get deleted?

I hadn't really thought they should be, just as oUserClass objects can't
be.  It might be nice if they could, from a memory saving point of view,
but I imagine in most OOPic projects you'd end up creating these things and
keeping them there for the lifetime of the program.

> - is there a significant advantage to this approach, or is it just
> something that appeals to a OOP guy?

Advantages I can think of:

1) Familiarity to C++/Java guys

2) Ability to define multiple classes in a single file, as the classes have
   their own typenames (like C structs) which would be handy for class
   libraries

3) Ability to declare class objects by name rather than path/filename.
   Just #include your class library and then start defining objects with the
   various class types.

4) Potentially the ability to copy classes.  You can copy structs, so why
   not classes?

5) Clarity - as user classes stand, a typical program may have several
   main() functions, in different files, and the main() of each user class
   is called implicitly.

> Some real world examples would help me here...

Think of it as an oUserClass with language closer to C/C++.  oUserClass
isn't even a proper VC object - it's merely a logical source construct.  My
proposal is to make it look more like a C++ construct (which semantically
it already is, as oUserClass, but it's declared and created in its own
quirky way).  The C-like aspect is that you could treat the created object
like a struct, which would have a type.  The C++-like aspect is that these
objects can have methods, as can oUserClasses.  The only additional feature
I suggested was replacing main() with something like constructor() for
clarity and to distinguish of from the 'true' main(), and allowing
arguments to be passed in to specify the object's initial state.

If I want to *really* put my OOP hat on, I'd add that we could also create
new classes by inheriting from others... :-)

Examples would be basically any oUserClass example, but in language terms I
think it would be cleaner.

Neil
-- 
Neil Durant
<nd...@us...>