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

[Andrew P. <wa...@ic...>]

At 03:23 AM 4/30/2004 +0100, Neil Durant wrote:
>Has anyone suggested implementing malloc to work in EEPROM, and providing
>pointer arithmetic?

That's sorta what I did with some of my library routines, so I'd assumed
we'd do something along those lines.


>> 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 suspect it's trivial to do.  It's all in the language definition, no?


>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.

Seems that way.


>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!".

Yes, most OOPicers would see this project as a mammoth task, but it ain't.


>  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....

No reason why neat features (like malloc, whatever) can't be provided to
BASIC users.  I would expect them to have access to most of it (do we give
BASIC #include and #define equivalents?)


>  [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!

Understood.


>> My immediate thoughts are:
>> - where does this thing get constructed?  RAM?  EEPROM?
>
>Exactly the same as existing oUserClass variables, which is presumably RAM.

OK.


>> - 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.

Which is a big fib.


>Were you thinking about removing 'new' and making OOPic object creation
>look more like global statics?

That's what I did with my preprocessor.  I'd vote for making "new"
optional, cuz it's a big fib.


>> - 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.

If new objects can't be created at runtime to reuse the space freed up by a
deleted object, then there's no point in deleting objects, so that makes
them static, so what's with this "new" keyword...  :)


>> - 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.

OK, I get it.


>> 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.

I hear ya.


...Andy