 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Darren New wrote:
>
>> The real problem is that most hackware is written by people who don't
>> know what they want. They don't figure out what they want to code to
>> do before they write the code.
>
> Personally, I don't know how the program is going to work until I've
> figured out how to write it.
Ah, but right there is the difference between documentation that you can put
in javadoc and documentation you can't.
"What does this do" is in no way related to "how does it do it".
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Similarly with CASE, you edit in the case tool and then regenerate the
> source code.
Yep. This assumes you can put everything into the CASE tool that you need.
If the CASE tool is only generating the skeleton, you need to be able to go
back, is what I was saying.
Not being able to go back and forth is one reason the CASE tools are so
expensive - they can't solve just the part they want to solve. They have to
solve the whole end-to-end thing.
--
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 wrote:
> Patrick Elliott wrote:
>> Its basically a mode flag, which when turned on, triggers,
>> "show_grab_handles", and, "disable_control", or something like the
>> second one.
>
> I see. That's kind of what I thought. I thought you were talking about
> the control doing something in the IDE, rather than the IDE driving the
> control.
>
>> Mind, a lot of this got easier with .NET,
>
> Yes. I never got into the design mode of COM stuff.
>
Yeah. Wish I hadn't. Wasted a lot of time trying to solve something that
just wasn't obviously solvable. Mind, I am sure you could work it out
with enough time to play with IDispatch, but I was looking to the
concrete example. I had wanted to design something that would allow you
to make a layout for a window, then export the settings to XML, and
later "reload" it. This would allow someone to make an importable layout
for different games, which could even be sent over on the fly, as
needed. The point was to avoid the overhead of needing the compiler
suite to make the layout, or worse, having to use something like IE to
"load" script and layout, when the client in question already had its
own, far more efficient, script system, and just lacked access to a way
to create custom windows.
Since then, some of these features have been added, but they are far
more limited than they would have been if you could have just plugged in
*any* control you wanted, instead of being limited only to those already
supported (which may be faster than COM, but adds more code and overhead
*in* the client itself).
The other issue we ran into was working out how to pull and IE and link
in such controls dynamically, so they didn't have to be "predefined",
and the client could pass on events from the attached control to the
script system. That is documented... sort of. The only example shows
using "one" control, in a very limited instance, doesn't go into detail
on any other aspects, and gives no example of how to properly handle
multiple copies of the control, *nor* several different controls. Sort
of a, "this is how to park your car in a single space, but not in a
crowded parking lot." In principle, someone with more understanding
could have worked it out. I didn't even have a "current" version of the
compiler to work with, which supported the API I needed. :p
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
>> In contract-oriented programming, how could you possibly break the
>> Order class by a change in the Customer class?
>
> By changing the contract of the customer class that the order class
> relies on. I haven't seen anything in a language where the order class
> could say what parts of the customer class's contract it relies upon.
Ah, I get that point now... my mental image had dependency the other way
round for some obscure reason.
Now that's a problem indeed: Changing a contract is a particularly
problematic change. Because that's why contracts are there in the first
place.
Note that a good contract places as many constraints on /both/ parties
as possible, to get some "room to breathe" in case either side needs to
be modified.
>>> The point I was making is that there are lots of paradigms
>>
>> I presume this sentence was left incomplete? (Otherwise: Erm... yes,
>> there are indeed lots of paradigms :-))
>
> Sorry. There are lots of paradigms that let you do things like change
> the type of a variable without having to have OO.
Maybe, but at any rate OO has been the most influential of these in the
last decades.
>> But my primary point was that the OO /paradigm/ was highly influential
>> in the creation of such type libraries - and that a non-OO approach
>> doesn't get you there, unless you somehow "emulate" OO behavior.
>
> Ehn. I'll disagree. I'll agree that container classes and GUIs both
> benefited tremendously from an OO treatment, but I'll also assert that
> non-OO modules and libraries (say, Ada83's) did nicely without the need
> for OO.
As my point is the tremendous benefit thing, I can live with that
assertion of yours.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
> Well, when you compile a C program, you don't then edit the generated
> machine code. You edit the original C program and recompile.
>
> Similarly with CASE, you edit in the case tool and then regenerate the
> source code.
That's the /theory/ :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Similarly with CASE, you edit in the case tool and then regenerate the
>> source code.
>
> Yep. This assumes you can put everything into the CASE tool that you
> need. If the CASE tool is only generating the skeleton, you need to be
> able to go back, is what I was saying.
>
> Not being able to go back and forth is one reason the CASE tools are so
> expensive - they can't solve just the part they want to solve. They have
> to solve the whole end-to-end thing.
True enough.
I think the main thing, though, is that there's generally not a huge
demand for CASE tools. Rational Rose lets me program in a diagram which
describes exactly how a given function executes, but... it would be
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.
I think perhaps the job could be quickER with something like Haskell,
since there are so few primitives to deal with. But even then, typing is
likely to be faster. (OTOH, with fewer primitives, maybe the reverse
transformation becomes more feasible...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
>>> Actually, Ada can do this too, I'm pretty sure, even without using
>>> its OO features.
>>
>> "Non-OO mainstream (imperative) language"?
>>
>> These languages all don't appear to fit that bill.
>
> You don't think Ada or Tcl is mainstream? Just because you haven't run
> into them doesn't mean they're not widely used.
My copy of Wikipedia categorizes Tcl as "multi-paradigm:
object-oriented, functional, procedural, event-driven programming"
(emphasis added; I haven't done enough Tcl coding to verify this claim)
- even though it does appear to be mainstream indeed, it doesn't seem to
fit the bill of "Non-OO ... (imperative) language".
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.
>> Though it wouldn't stand in the way of that.
>
> To some extent it would, depending on how your OO is integrated with the
> rest of your system. OO tends to have many references to one object
> scattered about in other objects. You have to avoid that if you're going
> to incrementally upgrade code as it runs.
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), or to "upgrade" only some
objects to the new implementation; 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Now that's a problem indeed: Changing a contract is a particularly
> problematic change. Because that's why contracts are there in the first
> place.
Right. This is why I laugh at all the people that tell me to just write unit
tests and everything will be fine.
> Note that a good contract places as many constraints on /both/ parties
> as possible, to get some "room to breathe" in case either side needs to
> be modified.
This assumes you're not making fundamental changes like adding a new level
of heirarchy to the product catalog or a new kind of management operation or
whatever. Depending on what you code in your contracts, they can really get
in the way.
> Maybe, but at any rate OO has been the most influential of these in the
> last decades.
Yes. See OP. ;-)
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
