"Barry Carr" <barrycarr@ixian-software.com> wrote in message news:Xns9460C663C917Ebarrycarrixiansoftwa@63.105.9.61...
> Hi Dave, Antti
>
> >>It is vital because an application should be a network of autonomous objects able to react to new situations (within reason) and work with derived classes without any trouble - as Liskov states. For instance: loading plugins at runtime (dlls are not adquate for this purpose as they don't allow access to objects unless you use COM); streaming in and creating objects etc. esp. if you're using an OODBMS; any form of data driven application is extremly difficult to construct without this facility. Having the ability to create instances dynamically adds an extra dimension of flexibility to your software at NO extra cost if the feature is support by the language.
> >
> > sounds so poethic. but is rather nonsence imho. i had never problems adding objects with dll's and all. you "think" too much oo. in the end, its all just binary code to execute. creating objects is just calling a function doing that. creating them by name only needs a factory wich can get runtime edited.
> >
>
> Thats the first time I ever heard it to be a bad thing to be too "OO". Alan Kay (the creator of Smalltalk) was right when he said (more or less): "I invented the term 'Object Oriented' and C++ wasn't what I had in mind". In my not so humble opinion, procedural code is degenerate, and closed for extension. How can being too "OO" be a bad thing?

Halleluyah! All power to his elbow. I think OO sucks no less (and no more) than procedural programming, or generic programming, or ADTs, or assembler. Anyone that thinks that any single paradigm is the answer to the programming problems one meets in the real world is a <moderator-snip> the kindest translation of the author's language would be "confused individual" </moderator-snip>. So I'm quite happy that C++ is not deemed to be OO by Smalltalk people. I just wish it wasn't deemed as an OO language by C++ programmers.

C++ is a programming language that supports multiple programming paradigms with equal facility. Apart from a few obvious ones, such as DbC mechanisms (in particular postconditions, since pre-conditions and invariants are largely trivial to support), it does that a sight better than any other language ... yet. Maybe D will be the one that beats it, but there's a long way to go before we can see that.

> > <snip>

Overall, I just don't get your feature request. If you're saying that D makes it impossible to provide binary-compatible objects to be loaded at runtime, then I say phooeey! Several years ago I invented (though I expect several have done so) a compiler-/platform-independent mechanism to do this in C++ - it's documented in Chapters 13 & 14 of my forthcoming book "Imperfect C++" - and it ran so well on so many different operating systems, and outperformed the previous system that it became the client's world standard programmable parsing architecture.

D makes several of the problems we encounter in C++ moot, so if anything it makes these none-too-difficult things even easier.

If you're saying that D should provide some of the admittedly boilerplate
aspects of these mechanisms, then maybe you have a point. But until and
unless you can provide a compelling example of such I'm afraid I must agree
with the others who have expressed befuddlement at the issues, or the
fundamental nature thereof, that you're putting
forth.

Let's have a practical example, with whatever pseudo-D you consider appropriate.

Cheers


Matthew Wilson

STLSoft moderator
    (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
    (www.synesis.com.au/articles.html#columns)

"If I'm curt with you it's because time is a factor. I think fast, I talk fast, and I need you guys to act fast" -- Mr Wolf

----------------------------------------------------------------------------
---

"Ant" <Ant_member@pathlink.com> wrote in message news:bss7ll$ded$1@digitaldaemon.com...
> In article <bsrlgc$2kcv$1@digitaldaemon.com>, davepermen says...
> >
> >and the battle goes on.. and gets rather big for this much too small
textbox..
>
> One of us didn't understand the issue.
> (it's probably me, don't worry;)
>
> I thought it was about extending/adapting an application
> through external and independent modules that would conform
> to some rules - let's say trought an implementation of an interface.
> The example of weapons and mosters is easy to understand.
> Another example is an IDE where all non core functionalities
> are provided externally (CVS access, code browser, what ever)
> Another example is an OS kernel that would load specific modules
> for different tasks/environments.
>
> how is D able to do that?
> (of course we can always start two processes
> with an ad-hoc "smart pluggin abstraction" layer between them
> and send messages across. But I guess that what
> J Anderson calls a work around)
>
> BTW what were Walter and Matthew talking about when replying to Mark's
post?

Can't remember the post or the reply. I was probably talking out of my arse, as usual.

Can you remind?

[also inline]

Sorry Barry, I am a bit brain-dead atm, so that may explain, but I just don't get it.

Can you answer me this question:

    What is there that you need that is not supported conceptually (and I
_mean_ conceptually, not all the registry, apartment, coding complexity) by
COM?

Cheers

Reginald


"Barry Carr" <barrycarr@ixian-software.com> wrote in message news:Xns9461CA745A134barrycarrixiansoftwa@63.105.9.61...
>
> Dave,
>
> I'm going to cut through all this BS. My position is this:
>
> C++ is too static. There are times (and I've cited two good examples) where  you need some runtime dynamicism to reduce coding, improve reliability and allow an application to adapt to new *SOME* new situations without falling flat on its face. This is not scripting, IMO, but the ability keep an application "Closed for modification, but open for extension" as Robert Martin states. Factories always require modification and thus break this rule. If you know different then show me an example factory as proof. If DMD has similar facilities or better, I'd like to see these too.
>
> I have work long enough with languages with dynamic facilities to know that a completely static languages are very restrictive and don't facilitate eligant, workable solutions - you end up having to code round situations to half get what you want. In my experience, the more dynamic a language is the more power the developer has at his or her disposal and the quicker they can get the job done. There is big role for compile-time facilities such as templates or generics as these can improve runtime performance and type safety, but these are still closed solutions.
>
> Furthermore, there is no reason to use procedural code anymore - OO technologies provide a much richer way of modeling problems and provide robust, extensible solutions to them. Objects implement algorithms to provide these solutions, not the other way round.

I'm checking my calendar here, and it's not saying 1st April. I hate being impolite on NGs to people I've not met but, mate, are you serious?!

Have you read *any* of Stepanov's writings on these issues. He's far more erudite than I am, so I won't even attempt to paraphrase; see http://www.stlport.org/resources/StepanovUSA.html. But I will quote some of the less blunt words:

"I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work"

Please read that article, if you've not already, and tell me where he is fundamentally wrong. I don't mean biased. Of course he's biased, as are we all wont to be. But is he fundamentally and completely wrong, and the Java/Smalltalk folks complete right? If so, you'd better tell the largest community of programmers in the world - the 5+ million C++ programmers - that they're wasting their time basing robust, extensible and *efficient* code on an intellectually bankrupt whim of a mathematically obsessed programming under-achiever. I think not.

(btw, I don't believe in 100% generics either. I don't believe in 100% anything. This puts me in a commanding position over anyone, from any camp, who does.)

> Virtual Machines are not uber-scripting languages, they are proper, complete languages in there own right and a realisation in the industry that a more dynamic runtime environment is required to provide timely, robust solutions.
>
> Now, if you don't agree with any of this, which you clearly don't - explain your counter arguments and cite examples.

I'd love to, but I don't find any of your postulates sufficiently concrete to grasp. For example:

"Virtual Machines are not uber-scripting languages, they are proper, complete languages in there own right and a realisation in the industry that a more dynamic runtime environment is required to provide timely, robust solutions."

I don't even know what that means. Please explain as if you're talking to an idiot as, in some respects, you are. ;)

> And I still want to know what if D has any dynamic facilities.

Yes and no. It has all the necessary mechanisms to do so, with difficulty. I cannot imagine it won't evolve (within the next 12 months) further mechanisms for making it easy to do. But I don't see it evolving to provide what you're talking about, for two reasons: (i) I don't really understand what you're after, (ii) it already addresses the main problem C++ has, the lack of an interface ABI, and will address the others such that dynamic facilities will be supported by compile-time techniques.

Cheers

Matthew

"qw" <qw_member@pathlink.com> wrote in message news:bst9qn$22k2$1@digitaldaemon.com...
> >"why do i want to create an object of unknown type?".
> The object has a known base class. For example, TMyClass. Or, the object descends from TComponent.

Then it's not unknown, is it? Or am I missing something

>Being a TComponent, you can obtain a
> list of properties. You obtain the properties and it's types and show them
in an
> object inspector. Congratulations, you have just built a GUI builder
> a-la-Delphi.
> In C++, you would have to register classes, register properties and types,
etc.
> I other words, you would have to build the whole framework from scratch.
Some
> parts may be easy, others are clearly not.

> I am by no means a guru at programming, I am Sun Certified Java programmer
> thats about all, Im not a
> professional, Ive only done one contract, but even I
> can grasp the concept of OO.

You don't need to qualify like this. Everyone gets a shot on this NG. :)

> You said earlier that Barry had a lot to learn, I believe that you are the one that has a lot to learn(about OO anyway) and maybe listening is a great part of learning.
>
> wow I cant believe that you can say this:
> ===========================
> "how does
>
> max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it
is
> a
> different part..
>
> programming happens on different layers. oo is one. procedural is another.
> "
> ===================
> that statement can return the contents of the greater one of two of the
> Objects data fields.
> You use procedural inside Objects on their data fields....

Hmm. This is a bad example on which to be arguing for OO, especially wrt D.

If a and b are related polymorphically, and provide different overloads of their comparison operators, then the result can depend on the order in which a and b are expressed to the function.

This is, in fact, a great example of how generics and non-member overloads are important.

>
> Phill.
>
> "He who asks is a fool for five minutes, but he who does not ask remains a fool forever."

How about: "He who learns from one who is learning drinks from a running stream"?

Why do we need a foreach in D? you can do it with a simple for loop. Or qhat do we need the for loop and the do-while loop for? We don't. We could do everything with a simple while. So they are senseless. Why do we have virtual methods? we don't need them. We could do the same with simple functionpointers. There are many things we don't neccessarily "need".

But We have it and use it very often. It's the same with reflection abilitys. This feature would be used less often than a foreach loop, but it would be used.

You could pass types arround at runtime without concerning about it. It simple makes life more compfortable as virtual methods do.

>I have work long enough with languages with dynamic facilities to know that a completely static languages are very restrictive and don't facilitate eligant, workable solutions - you end up having to code round situations to half get what you want. In my experience, the more dynamic a language is the more power the developer has at his or her disposal and the quicker they can get the job done. There is big role for compile-time facilities such as templates or generics as these can improve runtime performance and type safety, but these are still closed solutions.
>
Perhaps you should switch to Objective-C++. This language extends C++ by a Smalltalk like object system (like Objective-C does to C).

So you can use the extrem felxible features of Objective-C class when needed or use the powerfull compiletime stuff c++ offers, whe you prefer this in a situation.

My experience showed me that using the mvc-model it's pretty cool to do the
model in C++ and the view in objective-c and the controler brings both worlds
together.
At first ObjectiveC++ looks a bit strange as it looks like a simple mixture of
two languages, but whe you try it it turnes out that they fir toghether very
well.

>and about oo..
>
>how does
>
>max(a,b) { return a > b ? a : b; } gain anything with oo? not at all. it is a
>different part..
>
>programming happens on different layers. oo is one. procedural is another. generic another. patterns fit onto a top layer above them.
>
>only if you know to use all, you are really good at creating reusable code, that is dynamic even while static compiled. every c++ programer knows this. only brainwashed java/.NET programmers still think you always have to create a class around a static method.
>
That's exactly my opinion. Different paradigms for different tasks.



>and you haven't answered my question:
>
>if you know the type at code time (or a base of it, like IPlugin), then you can
>code with it. but then you don't need runtime object creation of unknown type,
>factory is enough.
>if you don't know the type at code time, then how do you code with it? eighter
>with some script at runtime, or.. how?
>you haven't answered that basic question. wich is the whole "why do i want to
>create an object of unknown type?".
>i simply don't understand what i should be able to use it for?
>
>and sorry for being that ignorant btw.. i simply don't get it. and i want to get it. but i don't know how yet.. you have to help me.. some applications showing how it adds really would be useful.
>

There are two basic types of OO: The Simula model and the Smalltalk model. They are pretty different.

Using a language based on the Smalltalk principles (e.g. Objective-C) the type never matters. These languages allways follow the rule: If something can be done a t runtime, do it at runtime, so you are as flexible as possible.

If you have an object you can send it a message. The object will respond to this message if it can. e.g. you could send "reverse" to an object. If it is a string it will reverse the order of it's characters. If it's a figure in a game it will turn around but it doesn't matter to the coder. This can be done very limited using the simula model with virtual methods, but the objects have to have the same base and you have to have a reference of a base type to invoke this method.


In languages using the Smalltalk model objects can often forward messages. If you send an object that you'd like to discuss something with it and it is a "warrior" he could delegate this message to a "diplomat" (is this the right word?) and you wouldn't even notice it.

[whatever discuss:"blabla"]; // here whatever turns out to be a warrior who delegates the message discuss:"blabla" to a diplomat, but you don't notice it. It looks like you'd directly use whatever (which is a warrior).


>and vm's are simply basecode to run scripts. binary scripts, but still scripts.

Yes and native executables are just scripts for the cpu!?! But this isn't what you normaly refer to as "script".

>> >"why do i want to create an object of unknown type?".
>> The object has a known base class. For example, TMyClass. Or, the object descends from TComponent.
>
>Then it's not unknown, is it? Or am I missing something
>


class MyClass {
}

class MyDerivedA : MyClass {
}

class MyDerivedB : MyClass {
}
..
int main ()
{
MyClass foo;

if (someCondition)
foo = new MyDerivedA;
else
foo = new MyDerivedB;


// OK, now tell me the type of foo.
// you can't as it's not known.
// OK you could using classinfo, but this is some kind of reflection, too
return 0;
}

>oo is a design on how to structure your objects, parts of oo is about
>> inheritance, or, what IS an object. the other is about encapsulation, or
>what
>> does an object LOOK like.
>
>my understanding of encapsulation is when a classes
>variables are made private and they have public get and set methods.

This understanding is simply crap. This is just plain stupid. Sorry fore being
that rude, but that's the way it is, at least if we are talking about
objectorientation.
I've seen this by many java-coders. Just make the variable private and write
public get and set routines for it.
Objectorientation is intended to abstract real objects. Encapsulation shoudl be
used to distinguish between implementation (what isn't interesting for the usage
of the object) and the "interface" which describes what the object can do. If
you write a get and set routine for a privat variable you loose the abstraction
completly. But abstraction is why you use objectorientation.


>> sure, every algorithm processes data. there is no "ergo algorithms are
>object
>> oriented". max doesn't bother AT ALL about objects. it is a generic
>working
>> algorithm. works with everything. i don't call an int an object.. i
>primarily
>> call it a number..

And what is a number? Some kind of abstract object. So it's not wron using it like, ... no ...., as an object. It depends on the situation whether this view is usefull or not. In a pure mathmatical problem it would be stupid. If the whole problem is about simple mathmatical problems it is somehow stupid to use a objectorientated language, as a functional one would fit much better.

>I dont call variables Objects either.

Could you please code C++ for one day. There variables represent object all the time, as all objects have value-semantics by defualt (opposed to reference-semantic as you're used to as a java-coder).


>I agree that Classes arent Objects, but Instantiated classes are Objects.
>And I would love to learn other languages and intend to eventually,  D in
>fact, which is no doubt why I
>am here.
There are languages where Classes are objects. Especialy in scripting languages this is very common.