Jump to page: 1 2 3
Thread overview
Document generator
Dec 04, 2004
Ant
Dec 05, 2004
Bastiaan Veelo
Dec 06, 2004
Ant
Dec 07, 2004
Bastiaan Veelo
Dec 07, 2004
Regan Heath
Dec 07, 2004
Bastiaan Veelo
Dec 08, 2004
Regan Heath
Dec 07, 2004
Ant
Dec 07, 2004
Bastiaan Veelo
Dec 05, 2004
Jan Bendtsen
Dec 06, 2004
Ant
Dec 07, 2004
gbatyan
Re: Document generator (String)
Dec 08, 2004
John Reimer
Dec 12, 2004
Hiroshi Sakurai
Dec 14, 2004
Ant
Dec 14, 2004
ahiru
Dec 14, 2004
Ant
Dec 14, 2004
ahiru
Dec 14, 2004
Ant
Dec 14, 2004
ahiru
Dec 14, 2004
Ant
December 04, 2004
This is more a curiosity then anything else
but I started a document generator from the
embeded comments on the source code
(as doxygen or javadoc).

For now it's intergrated with leds but it can be easelly decoupled.

see an example at:

http://dui.sourceforge.net/dui_ComboBoxTextEntry_ComboBoxTextEntry.html



Ant

December 05, 2004
At last, a D doc generator! Thanks Ant, looks like you are on the right track. Are "mixin"s in yet?

Bastiaan.

Ant wrote:
> This is more a curiosity then anything else
> but I started a document generator from the
> embeded comments on the source code
> (as doxygen or javadoc).
> 
> For now it's intergrated with leds but it can be easelly
> decoupled.
> 
> see an example at:
> 
> http://dui.sourceforge.net/dui_ComboBoxTextEntry_ComboBoxTextEntry.html
> 
> 
> 
> Ant
> 
December 05, 2004
Ant wrote:
> This is more a curiosity then anything else
> but I started a document generator from the
> embeded comments on the source code
> (as doxygen or javadoc).
> 
> For now it's intergrated with leds but it can be easelly
> decoupled.
> 
> see an example at:
> 
> http://dui.sourceforge.net/dui_ComboBoxTextEntry_ComboBoxTextEntry.html

This is great! Please keep up the good work, Ant. If this continues, your projects will end up overtaking phobos in terms of pure functionality and all-over object-oriented goodness :-)

BTW, what was the result of that String discussion a week or so back? Should we all stick to char[], or can we use a real String class in the future? Inquiring minds want to know (... attempting to incorporate dool into another package/project).

Cheers,
Dimon

December 06, 2004
On Sun, 05 Dec 2004 20:44:45 -0500, Jan Bendtsen wrote:

> Ant wrote:
>> This is more a curiosity then anything else
>> but I started a document generator from the
>> embeded comments on the source code
>> (as doxygen or javadoc).
>> 
>> For now it's intergrated with leds but it can be easelly decoupled.
>> 
>> see an example at:
>> 
>> http://dui.sourceforge.net/dui_ComboBoxTextEntry_ComboBoxTextEntry.html
> 
> This is great! Please keep up the good work, Ant. If this continues, your projects will end up overtaking phobos in terms of pure functionality and all-over object-oriented goodness :-)

for the object oriented - I hope so!

> 
> BTW, what was the result of that String discussion a week or so back?

Seems only I and Kris (from mango) agree.
The functionalities of my String class and his String class are similar.
We want to merge the names of those functionalities, seems we'll go
with verbose naming (ala java) instead the terse names used on phobos.
It's my move now but I'm getting distracted.

> Should we all stick to char[], or can we use a real String class in the future? Inquiring minds want to know

After the response from Walter (none) I would say vanilla phobos will never get a String class. It's one the flags Walter shows higher on D - not needing a String class.

> (... attempting to incorporate dool into another package/project).

dool will grow, if you find something missing just contribute it to dool.

Ant

December 06, 2004
On Sun, 05 Dec 2004 12:19:41 +0100, Bastiaan Veelo wrote:

> At last, a D doc generator! Thanks Ant, looks like you are on the right track. Are "mixin"s in yet?

no, not yet.
How should they be enumerated? just like the interfaces?
and then a link for each function/method?

>> see an example at:
>> 
>> http://dui.sourceforge.net/dui_ComboBoxTextEntry_ComboBoxTextEntry.html

The tags formating is drawfted - so the detailed comments looks better now.

Ant

PS
sourceforge CVS is ridiculous (hours to update) but dsource svn is usable.
I believe I'll be updating svn at dsource after every development session.

December 06, 2004
Jan Bendtsen wrote:

> BTW, what was the result of that String discussion a week or so back? 

Trenches were dug, a few rounds were fired, and everyone lost. :-P

> Should we all stick to char[], or can we use a real String class in the future? Inquiring minds want to know (... attempting to incorporate dool into another package/project).

D, being a multi-paradigm language, allows you to use both kinds...

If you are using function-data programming, you can use char[] type.
Or wchar[], for Unicode-heavy applications. And dchar for characters.
That is the approach that you will find in Phobos. (or C)

If you are using object-oriented programming, invent a String class.
It'll probably end up using some of the above for the implementation.
That is the approach that you will find in Dool. (or Java)

Which side to choose ? Sorry, can't help you. It's a war, you know...

--anders

PS. What Ant's dool is ? You can read this intro:
    http://dool.sourceforge.net/manifestDool.html
    (it's being used in DUI and leds for instance)
December 07, 2004
In article <pan.2004.12.06.01.59.07.161474@yahoo.ca>, Ant says...
>
>On Sun, 05 Dec 2004 20:44:45 -0500, Jan Bendtsen wrote:
>
>> Ant wrote:
>>> This is more a curiosity then anything else
>>> but I started a document generator from the
>>> embeded comments on the source code
>>> (as doxygen or javadoc).
>>> 
>>> For now it's intergrated with leds but it can be easelly decoupled.
>>> 
>>> see an example at:
>>> 
>>> http://dui.sourceforge.net/dui_ComboBoxTextEntry_ComboBoxTextEntry.html
>> 
>> This is great! Please keep up the good work, Ant. If this continues, your projects will end up overtaking phobos in terms of pure functionality and all-over object-oriented goodness :-)
>
>for the object oriented - I hope so!
>
>> 
>> BTW, what was the result of that String discussion a week or so back?
>
>Seems only I and Kris (from mango) agree.
>The functionalities of my String class and his String class are similar.
>We want to merge the names of those functionalities, seems we'll go
>with verbose naming (ala java) instead the terse names used on phobos.
>It's my move now but I'm getting distracted.
>
>> Should we all stick to char[], or can we use a real String class in the future? Inquiring minds want to know
>
>After the response from Walter (none) I would say vanilla phobos will never get a String class. It's one the flags Walter shows higher on D - not needing a String class.
>
>> (... attempting to incorporate dool into another package/project).
>
>dool will grow, if you find something missing just contribute it to dool.
>
>Ant
>

See my post, "OO & strings".

what do you think about that?




December 07, 2004
Ant wrote:
> On Sun, 05 Dec 2004 12:19:41 +0100, Bastiaan Veelo wrote:
> 
> 
>>At last, a D doc generator! Thanks Ant, looks like you are on the right track. Are "mixin"s in yet?
> 
> 
> no, not yet.
> How should they be enumerated? just like the interfaces?
> and then a link for each function/method?

Not sure what you mean. Do you have a link to an example with interfaces?

The thing is that besides generating documentation for the template itself, I think that classes that mix them in should have documentation with the mixins expanded, taking into account aliases. There is an earlier post with an example of what I mean.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11298

The point is that using mixins as a way of cutting down on the Copy&Pasting is an implementation detail, and should be hidden from the user, or at least be transparent.

>>>see an example at:
>>>
>>>http://dui.sourceforge.net/dui_ComboBoxTextEntry_ComboBoxTextEntry.html
> 
> 
> The tags formating is drawfted - so the detailed comments looks better now.

I am not concerned about looks yet. Getting the basics right is the real work :-)

Bastiaan.
December 07, 2004
On Tue, 07 Dec 2004 21:28:10 +0100, Bastiaan Veelo <Bastiaan.N.Veelo@ntnu.no> wrote:
> Ant wrote:
>> On Sun, 05 Dec 2004 12:19:41 +0100, Bastiaan Veelo wrote:
>>
>>> At last, a D doc generator! Thanks Ant, looks like you are on the right track. Are "mixin"s in yet?
>>   no, not yet.
>> How should they be enumerated? just like the interfaces?
>> and then a link for each function/method?
>
> Not sure what you mean. Do you have a link to an example with interfaces?
>
> The thing is that besides generating documentation for the template itself, I think that classes that mix them in should have documentation with the mixins expanded, taking into account aliases. There is an earlier post with an example of what I mean.
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11298
>
> The point is that using mixins as a way of cutting down on the Copy&Pasting is an implementation detail, and should be hidden from the user, or at least be transparent.

However, if you're reading documentation you don't really want to have to re-read the same thing 15 times to determine that it is indeed the same thing repeated 15 times.

Wouldn't it be better to link each mixin to one set of documentation so that once you've read it once you can immediately understand the use of it in each instance.

I guess before we can decide we'd need to see some concrete examples.

Regan
December 07, 2004
In article <cp53st$2agu$1@digitaldaemon.com>, Bastiaan Veelo says...
>
>Ant wrote:
>> On Sun, 05 Dec 2004 12:19:41 +0100, Bastiaan Veelo wrote:
>> 
>> 
>>>At last, a D doc generator! Thanks Ant, looks like you are on the right track. Are "mixin"s in yet?
>> 
>> 
>> no, not yet.
>> How should they be enumerated? just like the interfaces?
>> and then a link for each function/method?
>
>Not sure what you mean. Do you have a link to an example with interfaces?

here http://dool.sourceforge.net/dool_sql_dpq_DPQConnect_DPQConnect.html

so, create another horizontal line and put "mixins mixed in:" and further down a table with the links to the mixin function.

>
>The thing is that besides generating documentation for the template itself, I think that classes that mix them in should have documentation with the mixins expanded, taking into account aliases. There is an earlier post with an example of what I mean.
>
>http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11298

I see, I'm thinking it should be marked the function came from somewhere
else, like the javadoc makes a distintion on the methods inherited
from the super classes.

like:
---------------------------------------------
Class "Italy"

Documentation for Italy class.

Public Members:

Public member from mixin "Implementation":

void func( Pasta t ): Do something interesting with Pasta.
---------------------------------------------

>The point is that using mixins as a way of cutting down on the Copy&Pasting is an implementation detail, and should be hidden from the user, or at least be transparent.

the point is that now it's clear that any changes to "Implementation" will be propagated to class Italy.

>I am not concerned about looks yet. Getting the basics right is the real work :-)

not a joke (lessons in life - use carefully):
If you want to have success on our shallow society you have to change.
looks is every thing.
I already spent hours on my pages look an plan to improve them
more and more.
someone said "If you can't make it good, at least make it look good".

Ant


« First   ‹ Prev
1 2 3