In article <ceodr8$1bki$1@digitaldaemon.com>, Ant says...
>
>In article <ceob3h$1acn$1@digitaldaemon.com>, Stewart Gordon says...
>>
>>Just taken a brief look.
>>
>>"The second problem we find with phobos is that it isn’t a full OO library."
>>
>>By "a full OO library" do you mean one that uses OO for everything, even
>>  if it's overkill?  Leading to such things as
>>
>>	new DoublePrecisionFloatingPoint(1.5).sin
>
>no. math is an obvious exception (as long as it doesn't confuses dmd).
I should add primitive types also.

Ant

In article <ceobf6$1ag6$1@digitaldaemon.com>, Charlie says...
>
>>Nice.  Now we can say "there is no Phobos only dool!"
>>                                   Dana        Zool!
>>(lame ghostbusters reference)
>
>LOL got it!

I did consider drool as the name.
for D Runtime OO Lib.

and BTW when I named my DUI I didn't know it means Driving Under the Influense
and I also didn't remember that ant is that insect
(I knew about ant, just did connect.
'Ant' are the first 3 letters of my name.)

(Once a brother of a friend got excelent reviews on his coloring skills at kindergarden - later they found out he his colour blind... :)

Ant

In article <ceoemp$1bu0$1@digitaldaemon.com>, parabolis says...

>> hence, std.ctype gradually deprecated as replacements become available.

>That statement makes me nervous. I assume however that std.c.ctypes will continue to work with legacy apps?

Relax. I should have chosen my words more carefully. I probably should have said "hence std.ctype being gradually used less and less frequently, as better alternatives become available".

In any case, I have no influence over std. I presume Walter will do the sensible thing and continue to support the ctype functions indefinitely (documenting that they are defined only for ASCII characters, of course).

Jill

In article <ceoet0$1c4q$1@digitaldaemon.com>, Ant says...

>>no. math is an obvious exception (as long as it doesn't confuses dmd).
>I should add primitive types also.

Ah - that makes more sense. In that case, you don't need to wrap char, wchar or dchar, since these are primitive types.

I was thinking about what I posted earlier and some thoughts occur to me. Now that I've thought about it, I think it would be a bad idea to put an OO wrapper around dchar at all. Here's the reason.

Currently, if someone calls isLetter(dchar), and links with etc.unicode, the linker will add a small number of bytes to their executable - enough for a few small lookup tables and a function to access them. You're talking a couple of K at most.

On the other hand, a Char implementation would have to call /every/ Unicode function, and hence the linker would drag in /every/ function, including the exotic ones that hardly anyone's ever going to use, and the bloated getName() funtion, which returns, as an ASCII string, the name of every Unicode character. If you were to link to /the whole lot/, as a Char wrapper must do, you are going to pull in the /entire/ of etc.unicode. That's two megabytes. Although that may be justified in a DLL, no-one is going to want to add that to their executable.

You could make it smaller by choosing which functions to wrap and which to ignore, or to use unichar (with much the same effect), but, the more I think about it, the more I don't see the point. dchar is a primitive type. It doesn't need to be wrapped.

Arcane Jill

In article <ceoihh$1drt$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <ceoet0$1c4q$1@digitaldaemon.com>, Ant says...
>
>>>no. math is an obvious exception (as long as it doesn't confuses dmd).
>>I should add primitive types also.
>
>Ah - that makes more sense. In that case, you don't need to wrap char, wchar or dchar, since these are primitive types.


maybe not. It's java influence as most containers in java only support
objects. and also fear of the dreaded "std." conflict on dmd
(that might be converted into the "dool." conflict).

I see the math functions and the primitive types functions
almost as part of the language, not of the lib (yes, I'm that old),
so it makes sence to me that they be "free functions".


>I was thinking about what I posted earlier and some thoughts occur to me. Now that I've thought about it, I think it would be a bad idea to put an OO wrapper around dchar at all. Here's the reason.
[...]

valid.

Ant

Arcane Jill wrote:

> In article <ceoet0$1c4q$1@digitaldaemon.com>, Ant says...
> 
> 
>>>no. math is an obvious exception (as long as it doesn't confuses dmd).
>>
>>I should add primitive types also.
> 
> 
> Ah - that makes more sense. In that case, you don't need to wrap char, wchar or
> dchar, since these are primitive types.
> 
> I was thinking about what I posted earlier and some thoughts occur to me. Now
> that I've thought about it, I think it would be a bad idea to put an OO wrapper
> around dchar at all. Here's the reason.
> 
> Currently, if someone calls isLetter(dchar), and links with etc.unicode, the
> linker will add a small number of bytes to their executable - enough for a few
> small lookup tables and a function to access them. You're talking a couple of K
> at most.
> 
> On the other hand, a Char implementation would have to call /every/ Unicode
> function, and hence the linker would drag in /every/ function, including the
> exotic ones that hardly anyone's ever going to use, and the bloated getName()
> funtion, which returns, as an ASCII string, the name of every Unicode character.
> If you were to link to /the whole lot/, as a Char wrapper must do, you are going
> to pull in the /entire/ of etc.unicode. That's two megabytes. Although that may
> be justified in a DLL, no-one is going to want to add that to their executable.

I have doubts this is true. I have been debating how I feel about dool and one thing I tried was checking to see if a static function calling a class function would pull the data in. So I compiled with -O -inline -release and dumped using obj2asm and did not see any unused function names.

If you could give me an example I can try on my own I will be easily convinced. However I imagine Ch.isLetter() would probably have an almost identical method body as the etc.unicode.isLetter()?

In article <ceol8g$1f6q$1@digitaldaemon.com>, parabolis says...
>
>Arcane Jill wrote:
>
>> If you were to link to /the whole lot/, as a Char wrapper must do, you are going to pull in the /entire/ of etc.unicode. That's two megabytes. Although that may be justified in a DLL, no-one is going to want to add that to their executable.
>
>I have doubts this is true. I have been debating how I feel about dool and one thing I tried was checking to see if a static function calling a class function would pull the data in. So I compiled with -O -inline -release and dumped using obj2asm and did not see any unused function names.
>
>If you could give me an example I can try on my own I will be easily convinced. However I imagine Ch.isLetter() would probably have an almost identical method body as the etc.unicode.isLetter()?
>

this is great. back to the original idea.

Ant

"Ant" <Ant_member@pathlink.com> skrev i en meddelelse news:ceo2od$170c$1@digitaldaemon.com...
> dool is to complement phobos where phobos doesn't support he OO paradigm. read all about it at:

I'm a bit concerned about the usability of the project - if the manifest is to be taken literally.

For a library to be really useful, it needs to have stable interfaces, good documentation, and some formalism to ensure the quality of the implementation. Consider boost. It has both tests and peer reaview. You might consider to have two levels of quality: One for libraries that are somehow formally approved as production quality, and another for development. It then would make sense to use only production level libraries except for the parts where one self might participate in the development.

Then consider templates and mixins. Few people wants to use C++ without STL. Yet, the template mechanism isn't OO, and STL is not OO either. One of the things that makes is versatile, is that it decouples algorithms from data. Does "dool" exclude mechanisms such as templates and mixins?

Regards,
Martin M. Pedersen

In article <ceom81$1fns$1@digitaldaemon.com>, Martin M. Pedersen says...
>
>"Ant" <Ant_member@pathlink.com> skrev i en meddelelse news:ceo2od$170c$1@digitaldaemon.com...
>> dool is to complement phobos where phobos doesn't support he OO paradigm. read all about it at:
>
>I'm a bit concerned about the usability of the project - if the manifest is to be taken literally.
>
>For a library to be really useful, it needs to have stable interfaces, good documentation, and some formalism to ensure the quality of the implementation. Consider boost. It has both tests and peer reaview. You might consider to have two levels of quality: One for libraries that are somehow formally approved as production quality, and another for development.

that goes without saying (well apparently it doesn't)
I mean dool is just starting, expect changes, I believe it would be
the best way to get it to a rapid start.

>Then consider templates and mixins. Few people wants to use C++ without STL. Yet, the template mechanism isn't OO, and STL is not OO either. One of the things that makes is versatile, is that it decouples algorithms from data. Does "dool" exclude mechanisms such as templates and mixins?

I expect the templates to comply to OO and define classes.
(Alghout generic programming is not a new concept for me
I never actually used it before.)
I see mixins (a new concept for me) as complement of the single inheritance
OO paradigm.

Ant

Arcane Jill wrote:
<snip>
> On the other hand, a Char implementation would have to call /every/ Unicode function, and hence the linker would drag in /every/ function, including the exotic ones that hardly anyone's ever going to use,
<snip>
> That's two megabytes. Although that may be justified in a DLL, no-one is going to want to add that to their executable.
<snip>

Dead code elimination is one of the most fundamental optimisations ever invented.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.