I've done a little bit of code cleanup, using bool where apprioriate, reducing the memory footprint a bit, properly using enums/bitfields for flags etc.

Unfortunately there is no consistency in the types used in the code.
It even defines some types like d_uns32 but they are very sparsely used.

Even worse there's
// Be careful not to care about sign when using dinteger_t  <---
typedef uint64_t dinteger_t;
typedef int64_t sinteger_t;
typedef uint64_t uinteger_t;

     virtual dinteger_t toInteger(); <---
     virtual uinteger_t toUInteger();

So there's practically no difference between those functions? What's the
deal?
Why the inexpressive aliases?

I would personally love to have a set of types that look natural and clear
like in D, i.e. without some crappy prefix d_ or suffix _t like
int32,uint32,...
But in the end the point is to get some consistency.
Please comment.

Sure, the names used in dmd aren't particularly consistent... but do you really want to break every open pull request?

On Fri, Jan 27, 2012 at 11:15 AM,  <mrmocool at gmx.de> wrote:
> I've done a little bit of code cleanup, using bool where apprioriate, reducing the memory footprint a bit, properly using enums/bitfields for flags etc.
>
> Unfortunately there is no consistency in the types used in the code.
> It even defines some types like d_uns32 but they are very sparsely used.
>
> Even worse there's
> // Be careful not to care about sign when using dinteger_t ?<---
> typedef uint64_t dinteger_t;
> typedef int64_t sinteger_t;
> typedef uint64_t uinteger_t;
>
> ? ?virtual dinteger_t toInteger(); <---
> ? ?virtual uinteger_t toUInteger();
>
> So there's practically no difference between those functions? What's the
> deal?
> Why the inexpressive aliases?
>
> I would personally love to have a set of types that look natural and clear
> like in D, i.e. without some crappy prefix d_ or suffix _t like
> int32,uint32,...
> But in the end the point is to get some consistency.
> Please comment.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

mrmocool at gmx.de, el 27 de enero a las 01:15 me escribiste:
> I've done a little bit of code cleanup, using bool where apprioriate, reducing the memory footprint a bit, properly using enums/bitfields for flags etc.
> 
> Unfortunately there is no consistency in the types used in the code.
> It even defines some types like d_uns32 but they are very sparsely used.
> 
> Even worse there's
> // Be careful not to care about sign when using dinteger_t  <---
> typedef uint64_t dinteger_t;
> typedef int64_t sinteger_t;
> typedef uint64_t uinteger_t;
> 
>     virtual dinteger_t toInteger(); <---
>     virtual uinteger_t toUInteger();
> 
> So there's practically no difference between those functions? What's
> the deal?
> Why the inexpressive aliases?
> 
> I would personally love to have a set of types that look natural and clear like in D, i.e. without some crappy prefix d_ or suffix _t like int32,uint32,...

They are already there:
#include <stdint.h>
int32_t, uint32_t, etc. Sorry but C (and C++ in this case inherits
C stdlib) uses the _t suffix for typedefs.

Other than that, I think is a good idea, even if every pull request is broken. But then, who cares about what I think? :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Bald men with no jobs and no money who live with their parents don't
approach strange women.
	-- George Constanza

> Sure, the names used in dmd aren't particularly consistent... but do you really want to break every open pull request?

Hmm indeed a problem. Maybe one could only change those occurrences that
aren't changed in any pull request.
But in the end most of them are rather small changes that should be
trivial to rebase.

I also have a hunch that these types aren't used that much inside of methods, but rather as class member types or function return types. Most pull requests don't touch these.

I suspect they're mostly just used inside the interpreter and constfolding code, so maybe it wouldn't be that big a deal after all.

On Sat, Jan 28, 2012 at 3:22 AM,  <mrmocool at gmx.de> wrote:
>> Sure, the names used in dmd aren't particularly consistent... but do you really want to break every open pull request?
>
>
> Hmm indeed a problem. Maybe one could only change those occurrences that
> aren't changed in any pull request.
> But in the end most of them are rather small changes that should be trivial
> to rebase.
>
> I also have a hunch that these types aren't used that much inside of methods, but rather as class member types or function return types. Most pull requests don't touch these.
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals

>> I would personally love to have a set of types that look natural and clear like in D, i.e. without some crappy prefix d_ or suffix _t like int32,uint32,...
>
> They are already there:
> #include <stdint.h>
> int32_t, uint32_t, etc. Sorry but C (and C++ in this case inherits
> C stdlib) uses the _t suffix for typedefs.

I know. But _t doesn't look natural. In the end it's a D compiler, so why not introduce some good practice :)

mrmocool at gmx.de, el 27 de enero a las 17:38 me escribiste:
> >>I would personally love to have a set of types that look natural and clear like in D, i.e. without some crappy prefix d_ or suffix _t like int32,uint32,...
> >
> >They are already there:
> >#include <stdint.h>
> >int32_t, uint32_t, etc. Sorry but C (and C++ in this case inherits
> >C stdlib) uses the _t suffix for typedefs.
> 
> I know. But _t doesn't look natural. In the end it's a D compiler, so why not introduce some good practice :)

Well, it's a matter of taste really, I like the _t, I don't see how is a bad practice (in C at least makes a lot of sense). Also, even being a D compiler, is written in C/C++ and you already have those types there, I thought part of your improvements were to remove artificial typedef with strange names.

Anyway, I don't care that much...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
We are born naked, wet and hungry
Then things get worse

> Well, it's a matter of taste really, I like the _t, I don't see how is a bad practice (in C at least makes a lot of sense). Also, even being a D compiler, is written in C/C++ and you already have those types there, I thought part of your improvements were to remove artificial typedef with strange names.
>
> Anyway, I don't care that much...

Yeah, I know maybe practice isn't the right word.
Anyway, primarily I'd like to have consistent types (+ no senseless
typedefs, yes).

Secondarily I'd love to have types that at least look like they were builtin. But it's okay if that isn't desired.

mrmocool at gmx.de, el 28 de enero a las 00:54 me escribiste:
> >Well, it's a matter of taste really, I like the _t, I don't see how is a bad practice (in C at least makes a lot of sense). Also, even being a D compiler, is written in C/C++ and you already have those types there, I thought part of your improvements were to remove artificial typedef with strange names.
> >
> >Anyway, I don't care that much...
> 
> Yeah, I know maybe practice isn't the right word.
> Anyway, primarily I'd like to have consistent types (+ no senseless
> typedefs, yes).
> 
> Secondarily I'd love to have types that at least look like they were builtin. But it's okay if that isn't desired.

Well, you have to convince Walter, he is the only one deciding what's in and what's out... I was just commenting because you asked for comments :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Si ella es el sol, yo soy la luna
Si ella es el mar, soy el desierto
Y estamos en eclipse total
Y estamos en eclipse total