yet another project, yet another runtime lib.

I started this project to be able to continue development of my
lib DUI and my IDE leds. Since dmd 0.91 I have spend more time
with workarounds then development and I found a new OO lib to
be the long term solution.
dool is to complement phobos where phobos doesn't support he OO paradigm.
read all about it at:

http://sourceforge.net/forum/forum.php?thread_id=1121037&forum_id=394961

contributions to dool all welcome (OO only).

the next versions of DUI and leds will use the new library.
On leds it will be completly tranparent to the user,
on DUI the impact to the developer is minimal.

I also setup the CVS on sourceforge for my 3 active D projects.

There is nothing to see on dool yet, it contains just a few adaptations
from phobos (String, Path, File and not much else) and it was done
in a rush just to be able to compile DUI and leds.
however check the manifest on the sourceforge forum (the link above).

(sourceforge is a bit strange, it reports nothing on CVS but all the projects
are there.)
As I could do nothing more then workarounds, convertion to dool and but fixes
on the past few month the DUI and leds versions
on the CVS are **NOT** better then the current releases.
If you have nothing better to do and are very curiouse about these
projects by all means grab the CVS (but would will be on your own)
you can also browse the CVS from the sourceforge pages
(for instance cvs.sourceforge.net/viewcvs.py/dool/ ).

http://sourceforge.net/projects/dool/ (no home page yet) http://dui.sourceforge.net/ http://leds.sourceforge.net/projects/

(I hope to submit my projects to dsource soon.)

Ant

In article <ceo2od$170c$1@digitaldaemon.com>, Ant says...
>
>yet another project, yet another runtime lib.
>
>I started this project to be able to continue development of my
>lib DUI and my IDE leds. Since dmd 0.91 I have spend more time
>with workarounds then development and I found a new OO lib to
>be the long term solution.
>dool is to complement phobos where phobos doesn't support he OO paradigm.
>read all about it at:
>...
>

That's good to hear, it's specially adequate for programmers that like Java's way. :)

In article <ceo2od$170c$1@digitaldaemon.com>, Ant says...

>dool is to complement phobos where phobos doesn't support he OO paradigm. read all about it at: http://sourceforge.net/forum/forum.php?thread_id=1121037&forum_id=394961

Excellent! You have my wholehearted support.

Just a couple of minor points. (1), I read: "std.conv -> Integer (rename to
Int?)". I realize these are in different namespaces, but there already exists a
class called Int (my unlimited precision integer class). Might I suggest that
the name Integer be retained to avoid conflict?

(2), I read: "std.ctype -> Charater (rename to Char?)". (I assume that was a typo for "Character"). The problem here is that std.ctype does /not/ deal with Unicode characters, only with ASCII characters. It is useful for recoding old legacy applications, but new ones should be encouraged to use Unicode, and, hence, std.ctype gradually deprecated as replacements become available. Right now, Hauke's utype module replaces the ctype functions with Unicode functions having the same name, and, even more comprehensively, there are (non-OO) functions in etc.unicode which provide vastly more character properties - almost all of the properties defined by the Unicode Consortium right now, in fact, and absolutely all of them in the future. A new version of etc.unicode will, I hope, be available next weekend, complete with linkable lib. I guess what I'm saying is, I'd rather see an OO wrapper around etc.unicode than around std.ctype. If c is an instance of a Character/Char, you should be able to do: if (c.isBidiControl()) {...}, or if (c.isNonCharacterCodePoint()) {...}, or access any of the other Unicode properties, defined for /every/ Unicode character.

So I would like to suggest that a class which wraps only std.ctype should, in fact, be called neither Character nor Char. It should be called: ASCIICharacter or ASCIIChar. I suggest that Character/Char be reserved to wrap the etc.unicode character functions. As of next weekend, the code which builds etc.unicode will be uploaded to dsource/Demios - which is open source - so you can import it directly instead of having to re-implement it, and if you find any bugs you can get at the source to fix them instead of having to wait for fixed to Phobos.

I think your idea is brilliant. This is just a plea for consistency and co-operation in naming and forward planning.

Arcane Jill

In article <ceo686$18ks$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <ceo2od$170c$1@digitaldaemon.com>, Ant says...
>
>>dool is to complement phobos where phobos doesn't support he OO paradigm. read all about it at: http://sourceforge.net/forum/forum.php?thread_id=1121037&forum_id=394961
>
>Excellent! You have my wholehearted support.
>
>Just a couple of minor points. (1), I read: "std.conv -> Integer (rename to
>Int?)". I realize these are in different namespaces, but there already exists a
>class called Int (my unlimited precision integer class). Might I suggest that
>the name Integer be retained to avoid conflict?

just because Integer and Character sound too javaish, suggestion accepted (until some thing better comes up).

>
>The problem here is that std.ctype does /not/ deal with Unicode characters, [...]
> Hauke's utype module replaces the ctype functions with Unicode functions
>having the same name, and, even more comprehensively, there are (non-OO)

so, if it's open source, maybe Hauke's utype could be converted to OO and replace dool's current Character implementation. That's exactly one of the objectives of dool: easy to change and adopt the best solution available.

>So I would like to suggest that a class which wraps only std.ctype should, in fact, be called neither Character nor Char. It should be called: ASCIICharacter or ASCIIChar. I suggest that Character/Char be reserved to wrap the etc.unicode character functions.

ok, sounds good.

>As of next weekend, the code which builds etc.unicode will be uploaded to dsource/Demios

I'll probably take a look at it.
(be awere that my understanding of Unicode problems is very limited)

>I think your idea is brilliant. This is just a plea for consistency and co-operation in naming and forward planning.

thanks

Ant

In article <ceo2od$170c$1@digitaldaemon.com>, Ant says...
>
>yet another project, yet another runtime lib.
>
>I started this project to be able to continue development of my
>lib DUI and my IDE leds. Since dmd 0.91 I have spend more time
>with workarounds then development and I found a new OO lib to
>be the long term solution.
>dool is to complement phobos where phobos doesn't support he OO paradigm.

Nice.  Now we can say "there is no Phobos only dool!"

(lame ghostbusters reference)


Sean

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

instead of the more natural notation?

By "problem" do you mean "problem for OO purists"?  As the overview says, D isn't meant for purists.

But indeed, some bits of Phobos (like std.date) could do with being OO.

FTM, would structs and unions be allowed as well as classes?  Or do you consider those just another "legacy C++ construct"?

"- dool will not contain legacy C++ constructs (pointers are the obvious example)"

Do you have an alternative to a pointer into an array that achieves the same level of efficiency?

FTM, I'm not sure how you're going to interface many OS APIs without using such things at all....

"- new functionalities are always accepted (the exceptions are obvious and include malware, legal, and broken submissions)"

Why do you only want illegal stuff?

- std.conv -> Integer (rename to Int?)
- std.ctype -> Charater (rename to Char?)

Depends whether you're going to stick to one naming convention throughout all object wrappers for primitive types.

Two possibilities: make them all the same as the same as the D type names, or make them all unabbreviated names....

Stewart.

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

>Nice.  Now we can say "there is no Phobos only dool!"
>                                   Dana        Zool!
>(lame ghostbusters reference)

LOL got it!

Charlie

In article <ceo9bc$19oo$1@digitaldaemon.com>, Sean Kelly says...
>
>In article <ceo2od$170c$1@digitaldaemon.com>, Ant says...
>>
>>yet another project, yet another runtime lib.
>>
>>I started this project to be able to continue development of my
>>lib DUI and my IDE leds. Since dmd 0.91 I have spend more time
>>with workarounds then development and I found a new OO lib to
>>be the long term solution.
>>dool is to complement phobos where phobos doesn't support he OO paradigm.
>
>Nice.  Now we can say "there is no Phobos only dool!"
>
>(lame ghostbusters reference)
>
>
>Sean
>
>

In article <ceo7qf$192s$1@digitaldaemon.com>, Ant says...

>> Hauke's utype module replaces the ctype functions with Unicode functions
>>having the same name, and, even more comprehensively, there are (non-OO)
>
>so, if it's open source, maybe Hauke's utype could be converted to OO and replace dool's current Character implementation. That's exactly one of the objectives of dool: easy to change and adopt the best solution available.

Hauke?

I'm not sure I should be speaking on someone else's behalf, but I'm fairly sure uchar is open source in the sense that the source is public. Hauke posted it on this forum once. I'm sure he could be persuaded to post it again. I have no idea what license he uses. I don't know if it's hosted on dsource or anywhere else.

That said, the original (and possibly current) version of uchar worked by wrapping functions from unichar (another of Hauke's modules), rather than functions from etc.unicode. Though undeniably excellent, unichar has now been succeeded by etc.unicode in the sense that the functionality of unichar is a subset of the functionality of etc.unicode, and the latter library makes the presumption of aspiring to become a complete implementation of all Unicode algorithms ... eventually (wheras unichar only handles the most common character properties). So you have a choice of which implementation to wrap. unichar is going to smaller; etc.unicode is going to be more comprehensive - take your pick. Obviously, where they overlap, they should give identical results (assuming that unichar was built against Unicode 4.0.1).

The future is more interesting. I believe I am correct in saying that Hauke and I are in agreement that there should be only one Unicode implementation, not two rivals. I've been out of action for a while (but I'm back now), and once the etc.unicode codebuilder goes open source, Hauke will have write access to it, and I know he's pretty good at improving efficiency, as well as understanding the issues. So, I /think/ that etc.unicode is the way to go, most especially if uchar could be rewritten to wrap etc.unicode functions. But, like I said, I'm not sure I should be speaking on someone else's behalf. I'm hoping Hauke will join in here and speak for himself.



>>So I would like to suggest that a class which wraps only std.ctype should, in fact, be called neither Character nor Char. It should be called: ASCIICharacter or ASCIIChar. I suggest that Character/Char be reserved to wrap the etc.unicode character functions.
>
>ok, sounds good.

Regardless of the future of Character/Char, the main thing is to name the std.ctype wrapper ASCIICharacter/ASCIIChar, so as (a) not to mislead people, and (b) not to tie up the more general name for later.


>>As of next weekend, the code which builds etc.unicode will be uploaded to dsource/Demios
>
>I'll probably take a look at it.
>(be awere that my understanding of Unicode problems is very limited)

In general, there are a bunch of functions in etc.unicode with names like
getXxxxx(dchar) or isXxxxx(dchar), for instance getHexValue(dchar) or
isLetter(dchar). These functions are pretty easy to understand, and you can use
them just like the old ctype functions. (The functions do have different names,
I'm afraid, but Unicode property names are defined by the Unicode standard, not
by me). The more complex algorithms are yet to come, so actually there's not
much to understand at this point.

Jill

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).

>By "problem" do you mean "problem for OO purists"?

Obviously.

>  As the overview says, D isn't meant for purists.

but dool is.

>
>But indeed, some bits of Phobos (like std.date) could do with being OO.
>
>FTM, would structs and unions be allowed as well as classes?  Or do you consider those just another "legacy C++ construct"?

You saying the final classes should be Structs? Why not? probably.
I do use structs. (java does not define OO BTW)
structs can't implement interfaces, that might be the big problem.
(sorry if "legacy C++ construct" doesn't fit well. the first help
dool could have is a revision of the manifest...:)

>
>"- dool will not contain legacy C++ constructs (pointers are the obvious example)"
>
>Do you have an alternative to a pointer into an array that achieves the same level of efficiency?

no, but do I care? if your goal is speed you might want
to use another lib (complementing dool or not).
String it self might present an effitiency drop over char[].
beside, I might be wrong and adopt different ideas :)
probably the internal implementation should be irrelevant.
(I was wrong once: I thought I had made a mistake but I didn't.
My boss told me that joke :)

>
>FTM, I'm not sure how you're going to interface many OS APIs without using such things at all....

I mean the user API.
A programmer has to do what a programmer has to do.
(An old reference for the movie fans)

>
>"- new functionalities are always accepted (the exceptions are obvious and include malware, legal, and broken submissions)"
>
>Why do you only want illegal stuff?

Sorry, probably it reads the opposit way I wanted it :{ (?)
(I hope I can change it - I wrote that and revised it on separate days
and still has many, many mistakes... :( )

>
>- std.conv -> Integer (rename to Int?)
>- std.ctype -> Charater (rename to Char?)
>
>Depends whether you're going to stick to one naming convention throughout all object wrappers for primitive types.
>
>Two possibilities: make them all the same as the same as the D type names, or make them all unabbreviated names....

sure, makes sence.

Ant

Arcane Jill wrote:

> (2), I read: "std.ctype -> Charater (rename to Char?)". (I assume that was a
> typo for "Character"). The problem here is that std.ctype does /not/ deal with
> Unicode characters, only with ASCII characters. It is useful for recoding old
> legacy applications, but new ones should be encouraged to use Unicode, and,
> hence, std.ctype gradually deprecated as replacements become available. Right

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

> now, Hauke's utype module replaces the ctype functions with Unicode functions
> having the same name, and, even more comprehensively, there are (non-OO)

What does Unicode need with negative infinity? :)