>wich is just a mather of abstracting dll/so loading code, wich is one class and one function..
>
>wow.
>
>that was hard.
>

I have no problem with that. To me it never matters whether something is part of the language or part of the library, while I normaly even prefer it to be part of the library. (E.g. I don'T understand why we have hashes as a part of the language).

If you could write such a gneral loader, and it works fine, I'm sure Walter will concider it as being part of the next release.

hashes are part of the language because maps/hashmaps are an often used feature, and adding them to the language lets one write rather complex constructs in a nice, clean way..

it wouldn't be as clean at all to write in stl style in c++.

i'm not using linux at all, but i'm using an abstraction to win32 dlls since long time to do such stuff with dlls.. using com interface because else the gc has stress managing both sides, exe and dll..

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bvdjc1$2tie$1@digitaldaemon.com...
> >wich is just a mather of abstracting dll/so loading code, wich is one
class
> >and one function..
> >
> >wow.
> >
> >that was hard.
> >
>
> I have no problem with that. To me it never matters whether something is
part of
> the language or part of the library, while I normaly even prefer it to be
part
> of the library. (E.g. I don'T understand why we have hashes as a part of
the
> language).
>
> If you could write such a gneral loader, and it works fine, I'm sure
Walter will
> concider it as being part of the next release.
>
>

>and what do you use the type for? for creating instances? so all you need to pass around is some
>
>delegate IBaseClass create();
>
>or not?

As I said, this can be emulated without any problems. Yes, right.

>i see your point, but i simply see NO use for it. except if you, at runtime, want to inform the AppUser for stuff. and let him use that knowledge. and that means scripting (scripting is, letting the user (re)program parts of the program)

The "passed type" could depend on anything, on something you've read from a database, on a click by the user on a button. This depends very much the situation.

It would only save some code, if you could pass types arround. Without you have to write a function for each type you want to pass around. That's all.

>hashes are part of the language because maps/hashmaps are an often used feature, and adding them to the language lets one write rather complex constructs in a nice, clean way..

So a "int[char] foo;" is much better than a "hash!(int, char) foo;"? And what about linked lists? Why aren't they part of the language? They are used very often, too, epecially by those who like the functional paradigm.

never ever used linked lists myself yet..

but yes, int[char] is bether htan hash!(int,char), espencially if you have complex arrays in each other.. the value[key] syntax is very natural and fits well into more complex situations..

but yes, it's just sugar.

on the other side, there is more reason for a map-implementation to get into
the language as a linked list. why? because linked lists and dynamic arrays
have the same features (not in performance, but they are both essencially
dynamic arrays..).
maps are something else. they are a key-value-container, and due that often
needed in situations an array itself doesn't work anymore..

so yes, a language should have (at least) one dynamic array data type, and
one (or more) map data types.

linked list doesn't give you anything really.. there was, once, a proposed
way, sort of this:
type[^] will be the same as list!(type)..

just as type[] will stay vector!(type)

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bve19q$i82$1@digitaldaemon.com...
> >hashes are part of the language because maps/hashmaps are an often used feature, and adding them to the language lets one write rather complex constructs in a nice, clean way..
>
> So a "int[char] foo;" is much better than a "hash!(int, char) foo;"? And
what
> about linked lists? Why aren't they part of the language? They are used
very
> often, too, epecially by those who like the functional paradigm.
>
>

templated functions?

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bve146$i00$1@digitaldaemon.com...
> >and what do you use the type for? for creating instances? so all you need
to
> >pass around is some
> >
> >delegate IBaseClass create();
> >
> >or not?
>
> As I said, this can be emulated without any problems. Yes, right.
>
> >i see your point, but i simply see NO use for it. except if you, at
runtime,
> >want to inform the AppUser for stuff. and let him use that knowledge. and
> >that means scripting (scripting is, letting the user (re)program parts of
> >the program)
>
> The "passed type" could depend on anything, on something you've read from
a
> database, on a click by the user on a button. This depends very much the situation.
>
> It would only save some code, if you could pass types arround. Without you
have
> to write a function for each type you want to pass around. That's all.
>
>

To me that seems a perfect example of interface-based programming. You know, separating interface from implementation. That's a core OO concept, btw.

(Sorry for sarcasm, but your example does not serve your purpose)

"Matthias Becker" <Matthias_member@pathlink.com> wrote in message news:bvd9hr$2c9u$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
> >
>
>
> 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;
> }
>
>

i don't see scripting as something bad. but here we talked about having sort of reflection in. and all stated we need reflection, even without scripting. and i see no use for reflection outside of scripting situations at all. while i don't even require reflection for scripting, that is.

scripting is useful. reflection is very questionable.

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bvdb60$2gcq$1@digitaldaemon.com...
> >most the time you don't need more. you need only if you want at runtime inspection of the actual members and all. but how often do you need that,
i'm
> >curious. and as far as i know only when you want to bother with that
runtime
> >inspection, a.k.a. do something at runtime with it. and that, by default,
means
> >scripting. (scripting == creating new program flow at runtime.. a console
in a
> >game is a small scripting engine, for example.. it can be invisible,
behind a
> >gui, too, and is still there).
>
> And why do you consider some kind of "scripting" in a program as bad?
>
> >
> >i KNOW java makes it nicer. but its not MUCH code. and its definitely
DOABLE.
> >there is no need to get a class object, to only call myClass.new() on it.
if you
> >know what interface you want, you can just have a factory doing it. (the
above
> >given function IS a factory..).
>
> But you still have to write a factory.
>
>
>

>never ever used linked lists myself yet..

Never? Interssting.

>on the other side, there is more reason for a map-implementation to get into
>the language as a linked list. why? because linked lists and dynamic arrays
>have the same features (not in performance, but they are both essencially
>dynamic arrays..).
>maps are something else. they are a key-value-container, and due that often
>needed in situations an array itself doesn't work anymore..

But what about sets? Why isn't there a set in the language? What about sorted
structures (trees)?


>linked list doesn't give you anything really.. there was, once, a proposed
>way, sort of this:
>type[^] will be the same as list!(type)..
>
>just as type[] will stay vector!(type)
>

Well, if implemented right, they can give you a lot. Have you ever used a functional lanugage like Haskell or something? Imagine you want a list of all Elements smaller than a threshold. Using linked lists that could be nicly written as:

Type[^] filter (Type[^] list, Type threshold)
{
if (list.head < threshold)
return new Type[^](list.head, filter(list.tail, threshold));
else
return filter(list.tail, threshold);
}


As allways: Using some helper functions you can do the same with dynamic arrays as convenient (but slower).

i actually used in c++ days only vectors and maps..

now i use [] and [type]..

never needed something else.

but of course, it would be useful for some.

no, i never used functional languages by myself yet

"Matthias Becker" <Matthias_member@pathlink.com> schrieb im Newsbeitrag news:bvigp2$1trp$1@digitaldaemon.com...
> >never ever used linked lists myself yet..
>
> Never? Interssting.
>
> >on the other side, there is more reason for a map-implementation to get
into
> >the language as a linked list. why? because linked lists and dynamic
arrays
> >have the same features (not in performance, but they are both essencially
> >dynamic arrays..).
> >maps are something else. they are a key-value-container, and due that
often
> >needed in situations an array itself doesn't work anymore..
>
> But what about sets? Why isn't there a set in the language? What about
sorted
> structures (trees)?
>
>
> >linked list doesn't give you anything really.. there was, once, a
proposed
> >way, sort of this:
> >type[^] will be the same as list!(type)..
> >
> >just as type[] will stay vector!(type)
> >
>
> Well, if implemented right, they can give you a lot. Have you ever used a functional lanugage like Haskell or something? Imagine you want a list of
all
> Elements smaller than a threshold. Using linked lists that could be nicly written as:
>
> Type[^] filter (Type[^] list, Type threshold)
> {
> if (list.head < threshold)
> return new Type[^](list.head, filter(list.tail, threshold));
> else
> return filter(list.tail, threshold);
> }
>
>
> As allways: Using some helper functions you can do the same with dynamic
arrays
> as convenient (but slower).
>
>