Overloads not returning appropriate info. [Field reflunkory]

Alex AJ at gmail.com
Tue Apr 9 16:30:53 UTC 2019


On Tuesday, 9 April 2019 at 14:59:03 UTC, Adam D. Ruppe wrote:
> On Tuesday, 9 April 2019 at 14:42:38 UTC, Alex wrote:
>> It basically proves my point that there are issues with D.
>
> The language is fine in this case, it is a bug in the library.
>
I didn't say the language. The point with the language is that it 
could have built in semantics to do reflection in a inform 
way(__traits is somewhat uniform but messy and then one has 
std.traits which then makes it not uniform).

> Though, I don't think the library can be fixed because the 
> language doesn't have facilities to express these things 
> through libraries.... but I also don't see the point in having 
> a library at all. You incur compile time and run time costs for 
> stuff you probably don't need and introduce another layer of 
> bugs.

There is no runtime costs. The library may not be efficient but 
it is a better design. It abstracts most of the crap away and 
provides a very natural and uniform interface in to reflection.

Ultimately the compiler itself should provide this information 
directly. It has all the information when it compiles and it can 
lazily instantiate whatever information it has to calculate when 
it is requested. It could be very efficient, it is just doing 
what __traits does but more naturally.

Reflection should be a first class semantic in D given D's heavy 
meta programming capabilities.



> Some of the lower level features are a little weird to see*, 
> but they are easy to use once you get to know them.
>
> * for example
>    static if(is(typeof(overload) Params == __parameters))
>
> to get the function parameter list (as the Params variable 
> there). It is a little weird looking, but it isn't really hard 
> to use.


The problem is that there is a semantic that supposedly exists to 
dot he same but fails. So it is not about weirdness but about 
non-uniformity. Why does it have to be that way? There is no 
reason, it is also a hack in the compiler. WHy not just wrap that 
code with something sane like

Type.Reflect!Parameters

?

This is exactly what my library does and it is a more sane 
looking solution. It's that simple. You can't disagree, you know 
it looks better(we could argue about the precise syntax but it is 
much better and more informative than what you posted).

Also, your snippet is meant to be used, later on, such as in a 
for each loop,

when we could do

static foreach(p; Type.Reflect!Parameters)

vs

static if(is(typeof(overload) Params == __parameters))
     static foreach(p; Params)


It's 50% savings in both line space and character space, it's 
much faster to understand, it is uniform and natural while the 
second case is ugly, confusing, and bloated.


My point is that THERE IS NO NEED for such things. It is ALL 
about syntax. It's just wrappers. There is no new functionality. 
I'm just trying to make things "look" better because things that 
"look" better are easier to comprehend. Look better means that 
they are more uniform with common practices and experiences and 
allow for easier navigation in memory space.

You may be ok with having to remember special cases here and 
their... but it is a defect.  Suppose you program in 10 languages 
regularly, those special cases then are an order of magnitude 
more to remember... suppose you do other things with your life. 
If you don't and all you do is program D then you don't feel it 
as bad, if you do lots of other things then these are speed bumps 
that slows one down for no good reason at all(if you have one, 
besides, "some one has to code the new syntax and it takes work 
to make it better" then I'd like to hear it).

What I see if you justifying bad syntax just to justify it 
because it exists. If I'm wrong you just have to give me 
meaningful reasons why that is not the case.

I'm not looking to be confrontational, I'm looking to make things 
better. If you are right about what you claim then you can back 
it up, if not you can't except with fallacious arguments. My mind 
is willing to be changed as long as the change is provably good, 
else there is no point in going backwards.


I think the only argument you have is "It already exists and 
works and is not too bad"... which may be a good enough argument 
for you but isn't for me. That type of argument can be used to 
prevent progress on anything. "The cave is already exists and 
works to keep us sheltered and is not that bad so we don't need 
to build a nice house with AC that takes work to do". If all you 
have ever lived in is a cave then you can't possibly know if the 
house is better. It has to be built first to compare and 
contrast. The secret is that there is always something better 
than something else and it always should be sought after, at 
least theoretically(sure there is the practical issue of time, I 
accept that, but I don't accept denial that their isn't something 
better).


Hell, as much time that we have spent arguing over this shit we 
could have probably created a language feature that we both can 
agree is much better and is fast and really has no cons compared 
to what exists now.





More information about the Digitalmars-d-learn mailing list