Polishing D - suggestions and comments

[Kris]

"Dan" <murpsoft at hotmail.com> wrote in message 
news:fngu5g$2oi3$1 at digitalmars.com...
> Kris Wrote:
>
>>
>> "Jarrod" <qwerty at ytre.wq> wrote in message
>> news:fnfa1t$1o1g$2 at digitalmars.com...
>>
>> > What bugs me overall is not the rift between features on either side, 
>> > but
>> > rather the incompatibility issues. Unless there is a merge, there will 
>> > be
>> > two standards..
>>
>> Jarrod:
>>
>> In what manner does Tangobos not provide the "merge" you describe?  It
>> permits you to import, compile and link both phobos and Tango modules
>> without fuss (which is what people had asked for). If you have a 
>> different
>> idea of what that "merge" should instead be, would you please clarify?
>
> The thing they're asking for is a single semantically coherent library.


Many would say that is exactly the role of Tango ;)



> Essentially, take tangobos, make it "the" library, and then mix and match 
> redundant parts to get the best of each.

That's a nice proposition, though probably very hard to satisfy more than 
one person in reality?


> I'm a purist, so I dread the day that D's entire library infrastructure is 
> based on classes.  You can't tell me that the performance hit from classes 
> is trivial.


I'm somewhat of a purist also, and a strong proponent of efficient code 
(you'd know that if the conference videos had ever been released). Others 
involved with Tango are of a similar mind so, given that, permit me to point 
out some things you (and/or others) may not be aware of:

- You said "entire library infrastructure is based on classes", with perhaps 
a vague implication that's what Tango is about. This would be entirely false 
information, with the potential to mislead others. Phobos also has a number 
of classes, apparently in about the same ratio as Tango

- When it comes to performance there are always tradeoffs. For the most part 
(with one or two exceptions) we feel that Tango gets it right, though some 
disagree on the finer points. For example: there is one specific Tango class 
that gets some flack, yet in usage it often saves a significant amount of 
heap activity. One problem is that many people often see "new" and 
immediately go "aha!", while not bothering to profile anything in real 
usage.

- D has the scope keyword, which places classes on the stack (like a struct)

- When D finally gets struct ctors, Tango /may/ change one or two things.

I could go on, but the point is an old and boring one - don't judge a book 
by the cover. Tango is known to be significantly more efficient than phobos 
in all the ways we've tried in practice, and makes a concerted effort to 
design in a manner whereby heap-activity is minimized ... and to do so where 
it actually counts.  Honestly, it really wouldn't be worth all the effort 
otherwise ;)


> I see the best case being:
>
> 1) Establish a central repository of algorithms, such that anyone can 
> submit algorithms to the repository.
>
> - Committed algorithms would need to solve some problem domain, and would 
> not be trivially implemented with one-liners or other items in the 
> library.
>
> - Each algorithm could be versioned separately, and require review and 
> approval before being committed.
>
> - People ought to be able to sync their library to the standard 
> repository.  Perhaps by offering them read-only SVN access.  This would 
> let people revert to some old version of the standard library used to 
> compile a program 5 years, 3 months and a day ago.


What you describe is pretty much how Tango operates, and has done for the 
last year ;)

Cheers;