 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> drastically, *drastically* quicker to type this as text. The diagramming
> tool makes it take 10 times longer to do (more or less) the same job.
Which is why you need to be able to go back and forth, you see.
The *problem* with being able to go back and forth is that it really doesn't
add a whole lot of value if the two forms are isomorphic.
Which is why having a CASE tool generate a textual skeleton of code, and
then being able to change that skeleton and have the CASE tool able to
handle the changes, is probably the most effective way.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> - even though it does appear to be mainstream indeed, it doesn't seem to
> fit the bill of "Non-OO ... (imperative) language".
It's not OO. There's a library to make it look like it's OO. When you use
that library, each object is represented as a global procedure. It can kind
of sort of look OO, but it isn't.
> As for Ada: When I think "mainstream", I don't usually think avionics,
> weapon systems or spacecraft - or any other embedded or real-time
> application, for that matter.
OK. When I say "mainstream", I mean a language that's actually used for
actual development by people other than those at the same company where the
language was invented. I rule out things like Blue and Sing# and such, the
experimental languages crafted for a specific program to be written in.
I would say anything where you can go to Amazon and buy a textbook and then
download the compiler would have to be mainstream. If you have to download
the whitepaper that describes the language? That's not mainstream.
> As I said, it depends on the runtime. If for instance the runtime would
> store object references as a combination of a "data address" and a "type
> identifier", it would be more than problematic to add data fields (due
> to inability to move the object on the heap),
I think we can safely rule out upgrading running executable code for systems
that don't have automatic memory management.
> or to "upgrade" only some
> objects to the new implementation;
Nah. You'd just patch the type in the pointers that point to the new objects.
> if the runtime instead stores object
> references as pointers to memory blocks including both the data and a
> virtual method table, data size may still not grow, but implementation
> could be changed for individual objects of a type; and a runtime that
> happens to use chained references for garbage collection would have all
> the necessary power to actually relocate objects on the heap, thus
> allowing for arbitrary changes to the data structure. With such a
> runtime, your "object network" can be arbitrarily complex. Similar
> flexibility can be achieved by adding a level of indirection between the
> reference and the actual data.
The problem you might be missing is the existence of return addresses on the
stack that index into the code you're changing. If your objects sit around a
long time in various networks, and you can't tell which bits of running code
are using which objects (as in, have methods of those objects on the stack
for that thread), then you're going to have a hard time replacing the
objects without clobbering code that's already running. You're also going to
have a hard time running the old code in one thread and the new code in
another thread both using the same shared object.
I guess you could make the upgrades of an entire class at once, but you'd
have to make sure nobody is executing any methods in that class when you did
it. (I'm also implicitly assuming for good reason that few people are going
to want to upgrade a single-threaded process while it's running.)
It's sort of like trying to reorganize a SQL table while there's
transactions in progress on it. Messy.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> My copy of Wikipedia categorizes Tcl as "multi-paradigm".
...you downloaded the Internets?!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> clipka wrote:
>> - even though it does appear to be mainstream indeed, it doesn't seem
>> to fit the bill of "Non-OO ... (imperative) language".
>
> It's not OO. There's a library to make it look like it's OO. When you
> use that library, each object is represented as a global procedure. It
> can kind of sort of look OO, but it isn't.
Given that I have the impression that you accept as OO only what has a
certain runtime structure, instead of what aids in implementing an OO
design, I prefer to trust Wikipedia on this matter.
If it /feels/ like OO (i.e. it supports your attempts at implementing an
OO design), it /is/ OO.
>> As for Ada: When I think "mainstream", I don't usually think avionics,
>> weapon systems or spacecraft - or any other embedded or real-time
>> application, for that matter.
>
> OK. When I say "mainstream", I mean a language that's actually used for
> actual development by people other than those at the same company where
> the language was invented. I rule out things like Blue and Sing# and
> such, the experimental languages crafted for a specific program to be
> written in.
That would (for most part) match "production" language in my set of
definitions.
To be mainstream, something really needs to be... well, you know, in the
/main/ stream.
You wouldn't call some clothes fashion to be mainstream just because
people sell the clothes instead of sewing them at home for their own
personal use, would you? Or call some musical style mainstream just
because you can buy that type of music on audio CDs?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
>> My copy of Wikipedia categorizes Tcl as "multi-paradigm".
>
> ...you downloaded the Internets?!
Part of it, yes - typically every time I call up a page :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> you accept as OO only what has a certain runtime structure
No, I call something OO if it has more "OO" to it than (say) stdio.h. :-) It
needs objects, and data associated with objects, and stuff like that.
> If it /feels/ like OO (i.e. it supports your attempts at implementing an
> OO design), it /is/ OO.
Tcl's an extensible language. People have written libraries that emulate
some aspects of OO. Tcl is no more OO than C is OO because someone invented
cfront. Just like the existence of Candygram doesn't make Python an
actor-based language.
Tcl's OO works by creating a procedure for each object. Invoking that
procedure causes it to use the first argument as a string to look up the
method to run, and the name of the procedure itself as an index into a
global hashtable to find the data associated with the object. I guess if you
squint hard, you could say it supports OO. It's not what I'd call an OO
language, tho. It's a procedural imperative language with an optional and
not widely used lump of library that rewrites procedural code to look sorta
OO if you don't peer too close.
> That would (for most part) match "production" language in my set of
> definitions.
Fair enough. That, then. :) I was trying to distinguish "one-off
experimental languages designed specifically to aboid what I was talkign
about" from "real" languages. (Altho, honestly, at this point I've
forgotten what I'm talking about.)
> To be mainstream, something really needs to be... well, you know, in the
> /main/ stream.
> You wouldn't call some clothes fashion to be mainstream just because
> people sell the clothes instead of sewing them at home for their own
> personal use, would you? Or call some musical style mainstream just
> because you can buy that type of music on audio CDs?
No, but I'd call police uniforms "mainstream" even tho only policemen use
them. :-)
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> clipka wrote:
> > you accept as OO only what has a certain runtime structure
> No, I call something OO if it has more "OO" to it than (say) stdio.h. :-) It
> needs objects, and data associated with objects, and stuff like that.
> > If it /feels/ like OO (i.e. it supports your attempts at implementing an
> > OO design), it /is/ OO.
> Tcl's an extensible language. People have written libraries that emulate
> some aspects of OO. Tcl is no more OO than C is OO because someone invented
> cfront. Just like the existence of Candygram doesn't make Python an
> actor-based language.
I think one should distinguish between Object-Oriented Design (OOD) and
Object-Oriented Programming (OOP). While the distinction might often be
rather fuzzy, and often they are very tied together (because, after all,
implementing an OOD is often best done with an OOP language), they can
still be used independently.
For example, many programs have a full-fledged OOD but are then
implemented in a language which supports little to no OOP, most
typically C (and even when OOP is more or less "emulated" with C, only
very few actual OOP techniques are used).
(The other extreme might also be possible in some cases, ie. "abusing"
an OOP language for a design which has very little object-orientedness
in it. Could eg. be more akin to objects being "abused" for functional
design and programming techniques.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> For example, many programs have a full-fledged OOD but are then
> implemented in a language which supports little to no OOP, most
> typically C
Yep. That's what I'm saying. You can do "OOP" in any language, but a
language has to support it natively for *me* to call it an "OO language."
> an OOP language for a design which has very little object-orientedness
Sure. Any time you give other processes access to all the member variables,
or have most of the routines just static functions, or etc. :-)
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> > an OOP language for a design which has very little object-orientedness
> Sure. Any time you give other processes access to all the member variables,
> or have most of the routines just static functions, or etc. :-)
I think singletons are a completely valid OOP technique. (OTOH, if your
entire program consists of singletons, it becomes a bit dubious whether
your program is object-oriented at all...)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> > an OOP language for a design which has very little object-orientedness
>
>> Sure. Any time you give other processes access to all the member variables,
>> or have most of the routines just static functions, or etc. :-)
>
> I think singletons are a completely valid OOP technique. (OTOH, if your
> entire program consists of singletons, it becomes a bit dubious whether
> your program is object-oriented at all...)
Sure. I meant if all the objects/classes in the program have all the member
variables public and all the routines static, you're just using OO for the
modularity. Doing it that way occasionally doesn't hurt.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
