I know you tired of people sending post like "I have a new wonderfull idea.
Bla, bla, bla". And I know D already has too much features.
But take a look in this wonderfull, killer, amazing and powerfull feature:
:-)

MODULE VERSIONING

1 - Floating number representation

At lexical level a new representation of float literals is useful for many task including version numbers, tcp/ip numbers. It can be writed as:

    	float f = 1.25.4.0
    	float ip = 128.0.0.1

The adittional "." above represent the thousand decimal separator. See:

    	1.25.04.0 == 1.250004
    	128.0.0.1 == 128.000000001

2 - Assert contract have a option message describing the problem found

    	assert(int.size == 4, "This code will only run in 32 bits cpus");

3 - Module version

Each module could have a .version property and a .vendor property. They will be assigned within the module:

    	module mymod;

    	mymod.version = 1.02.1;
    	mymod.vendor = "Monkey$oft"

And this information could be used in for many reasons:

o    	Minimal implementation

    	import mymod;

    	unittest
    	{
    	    	assert(mymod.version >= 2.01, "You need the new version of that
module");
    	}

o    	Dealing with buggy code

    	unittest
    	{
    	    	assert(mymod.version != 1.2 && mymod.vendor == "DigitalMars",
"This version of mymod is buggy :-)");
    	}

o    	Adapting the application for diferent version of the same lybrary

    	if (glic.version in (2.1..2.2))
    	{
    	    	adaptForLegacy()
    	}
    	else
    	if (glic.version >= 2.3)
    	{
    	    	doTheOptimizedWay();
    	}


o    	Political wars

    	unittest
    	{
    	    	assert(mymod.vendor != "Monkey$oft", "We don't like
Monkey$oft.");
    	}

4 - Initial values

These properties need to be optional and initialized to:

.version  = nan;
.vendor   = "";

5 - Why not use a const version_id and vendor_name ?

o    	Not all modules will have versioning
o    	There are no standart way to verify what version that module
implements.
o    	Can support diferent library implementations.


Saudações

Juarez Rudsatz

"Juarez Rudsatz" <juarezNOSPAM@correio.com> wrote in message news:Xns933BCB5FD7416juarezcom@63.105.9.61...
> I know you tired of people sending post like "I have a new wonderfull
idea.
> Bla, bla, bla". And I know D already has too much features.
> But take a look in this wonderfull, killer, amazing and powerfull feature:
> :-)
>
> MODULE VERSIONING
>
> 1 - Floating number representation
>
> At lexical level a new representation of float literals is useful for many task including version numbers, tcp/ip numbers. It can be writed as:
>
>     float f = 1.25.4.0
>     float ip = 128.0.0.1
> The adittional "." above represent the thousand decimal separator. See:
>
>     1.25.04.0 == 1.250004
>     128.0.0.1 == 128.000000001

it may have escaped you but an ip addresses are 32 bit fixed point numbers not 1:7:24 floats so you can not use a float to hold an ip address (and v6 are bigger than double or long) if it was not for some merits to the other sugestions I would have been tempted to think about posting "dont feed the troll" and then take my own advice.

why not truple's instead of yet another build in specialised type.
I know 2d vectors and complex numbers are different, all though operations
on them do require
similar cpu instructions (magnitude is the the same op)
and complex multiply is close to 2d vector dot and cross
(p,q are complex of the for (a+ib) and (c+id); p', q' are vectors of the
form (a,b) (c,d)
p * conjegate(q) => ( dot(p',q') + i*cross(p',q')) // or somthing close
anyway

ip address is just 4 bytes ( or 4 ints for a v6 (3 ints and 4 bytes for
compatibly with v4)) // don't quote me on that its the idea I'm trying to
get across.

>

> 2 - Assert contract have a option message describing the problem found
>     assert(int.size == 4, "This code will only run in 32 bits cpus");
that or having the assert put the condition as a string in the message, so; assert( int.size == 4); would give "assert failed 'int.size==4' is not true at line xxxx in File yyyy"

>
> 3 - Module version
>
> Each module could have a .version property and a .vendor property. They will be assigned within the module:

as much as I like the idea, alas it still fails to catch the usual problem .... you forget to increment your version number.

the only automated solution I can see is allowing modules to be sectioned
each section has its "signature" hashed and that is stored both in the
module and any places it is imported.
adding a new function to a section changes that section (so old code will
not load the module)
adding a new section (without changing the names/params of the modules
classes etc) would allow oldcode to use the original interface (i.e.
original section) and newcode to also call into the new section.
classes and structures could also use this (may be with an included length
field as the first member) to detect the version (as windows does manually
for many structs) and thus the valid sections (append only so layout would
have to be ordered, new section at the end only (new virtual funcs at end of
vtbl etc).

Check out www.digitalmars.com/d/version.html

"Walter" <walter@digitalmars.com> wrote in message news:b4r8co$1ip1$1@digitaldaemon.com...
> Check out www.digitalmars.com/d/version.html
I C its a bit hidden
 version (ProfessionalEdition)
	{
	    version = FeatureA;
	    version = FeatureB;
	    version = FeatureC;
	}

could be

version (version_1_1_3_release)
{
    version = version_1;        // the original interface
    version = version_1_1;   // the bits we added for solve problem x
    version = version_1_1_3;  // the bug fixes to1_1_2 same i/f
}

that's great for building static app, but ... what about import libs do they contain the version symbols that where used ?

I couldn't find it at first either.  But it looks like a good feature to me.

I'm curious what the scope of those version specifications are though.  The webpage doesn't say.  My first impulse would be to give them the scope they're declared in, but it might be nice to be able to export them maybe, access public ones from other modules perhaps?

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b4r8co$1ip1$1@digitaldaemon.com...
> Check out www.digitalmars.com/d/version.html

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:b4r963$1j9e$1@digitaldaemon.com...
> that's great for building static app, but ... what about import libs do
they
> contain the version symbols that where used ?

No, they do not. Versioning of imports is probably best accomplished by appending a version number to the import name, and then using the version declaration and aliases to pick which version is to be used.

"Sean L. Palmer" <seanpalmer@directvinternet.com> wrote in message news:b4rsvv$20eh$1@digitaldaemon.com...
> I'm curious what the scope of those version specifications are though.
The
> webpage doesn't say.  My first impulse would be to give them the scope they're declared in, but it might be nice to be able to export them maybe, access public ones from other modules perhaps?

Their scope is at the module level.