View mode: basic / threaded / horizontal-split · Log in · Help
January 24, 2013
Re: [OT] Affect of typing styles on coding style (Was: Make dur a property?)
On Thu, 24 Jan 2013 09:47:32 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2013-01-24 06:16, Nick Sabalausky wrote:
> 
> > Heh, actually, case in point, take a look at my normal work setup:
> >
> > http://66.228.38.161/download/img/jobs-would-have-hung-employees-for-doing-this.jpg
> >
> > (Yes, I need to get a wireless keyboard/trackball ;) )
> 
> That's not a good work setup, in any way. Close the laptop and get a 
> real, external monitor, or two.

I do, just not hooked up ATM. Been meaning to.
January 24, 2013
Re: Make dur a property?
On Thu, 24 Jan 2013 09:52:38 +0100
Jacob Carlborg <doob@me.com> wrote:

> On 2013-01-24 00:16, Nick Sabalausky wrote:
> 
> > I'll certainly grant that, insofar as the written order is backwards
> > from the execution order. I think the "ago" is that part that bugs
> > me the most. It's too clever. I could live with "2.days", but I'd
> > prefer "days(2)" since that looks like a type constructor, and
> > "days" isn't a property of 2. Maybe "2.toDays()", but at that point
> > I'd still rather just do the simpler "days(2)".
> 
> If you don't have "ago" how would you determine the differences
> compared to the opposite,

now - blah vs. now + blah

> which looks like this in Ruby on Rails:
> 
> time = 2.days.from_now
> 
> "2" is the duration, "days" is the unit and ago/from_now indicates if 
> it's positive or negative.
>
January 24, 2013
Re: Make dur a property?
On 01/24/2013 04:02 AM, Nick Sabalausky wrote:
> On Thu, 24 Jan 2013 00:45:02 +0100
> Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 01/23/2013 11:46 PM, Nick Sabalausky wrote:
>>> On Wed, 23 Jan 2013 21:29:14 +0100
>>> ...
>>> Don't know if it's filed, but yea: Optional empty-parens and
>>> the practice of conflating properties with functions is riddled with
>>> corner-cases. We can either try to patch over these corner cases
>>> with increasingly detailed new rules,
>>
>> What are those "new" rules? The rules we already have are sufficient.
>> Now the compiler needs to implement them properly.
>>
>
> Andrei was just suggesting this:
>
> http://forum.dlang.org/post/kdpg5n$2qt2$1@digitalmars.com
>

This rule is not new. Also, it is about @property.

>>> as Andrei is proposing, or we
>>> can just accept "the writing on the wall" (if you'll pardon my
>>> 80's-ism) that properties != functions.
>>>
>>
>> That is not even the point of this discussion.
>>
>> a.map!(a=>foo(a,b).map!(a=>2*a)())().days().ago().writeln()
>>
>
> First of all, spacing helps:
>

I do not see that. It just blows up the code even more.

> a.map!( a => foo(a,b).map!(a=>2*a)() )().days().ago().writeln()
>
> So does not trying to cram everything into a one-liner:
>
> auto descriptiveName = a => foo(a,b).map!(a=>2*a)();
> a.map!descriptiveName().days().ago().writeln()
>

This is not valid code.

> And then there's a few () in there, but not only do I fail to see how
> those hurt anybody, they make perfect sense since "days", "ago" and
> "writeln" are not data access, they're actions (even if maybe a little
> too cutely-named in the case of "ago").
>

There is no universal rule that says () has any relevance for this.

(Arguably, it does not make any sense to distinguish concepts like 'data 
access' and 'action' syntactically. What is this distinction anyway?)

> (Of course, I'd question the meaningfulness and feasability of passing
> the "days" type constructor a range instead of a scalar, but I get that
> that's beside the point ;) )
>

No, that is spot on. I didn't even notice, which is partly owed to the 
paren spam.
January 24, 2013
Re: Make dur a property?
On 01/24/2013 10:52 AM, Nick Sabalausky wrote:
> now - blah vs. now + blah

Now we have caught you.
January 24, 2013
Re: Make dur a property?
On 2013-01-24 10:11, monarch_dodra wrote:

> IMO, it not currently doing so is a limitation

Yes, that's what I'm saying. You cannot swap properties and fields willy 
nilly using the current implementation.

-- 
/Jacob Carlborg
January 24, 2013
Re: Make dur a property?
On 2013-00-24 05:01, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com>  
wrote:

> On Wed, 23 Jan 2013 22:59:38 +0100
> "monarch_dodra" <monarchdodra@gmail.com> wrote:
>>
>> --------
>> IMO: We should be able to keep the optional parenthesis for all
>> functions (except maybe those that return delegates).
>
> I'm not a fan of that as I think the need for special-casing of
> functions returning delegates is not worth what I still don't see as a
> benefit.
>
> Side note: I know at least one person here likes this [ ;) ], but I
> really hate code like:
>
> foo.doStuff;
> foo.makeFizzBar;
> foo.updateBlorg;
>
> Have to do a double-take every time. Just looks like a bunch of
> no-ops, and sets off mental red flags every single time.

Amen!

I do understand Adam's view that foo.bar(10).baz(5) be allowed,
but that could be written with(foo){bar=10;baz=5}. Admittedly more
verbose, but also clearer.

On that topic, I occasionally do miss C#'s object initializers,
particularly because they could allow for immediate creation of many
const and immutable values.

-- 
Simen
January 24, 2013
Re: [OT] Affect of typing styles on coding style (Was: Make dur a property?)
On Thursday, 24 January 2013 at 05:16:32 UTC, Nick Sabalausky 
wrote:
> I think that shows how different editors or even just personal
> typing styles can affect our coding style. For me, I'll do 
> stuff like:


Aye, I think this applies to my non-caring about identifier name 
length too - I use tab completion in my editor.

I've tried some of those auto parens things, and it just confuses 
me. I guess I could get used to it (I recently started playing 
one of those newer shooter games. I come from Perfect Dark on the 
N64, so I'm used to what Halo called "legacy controls". The new 
controls were totally unusable to me.... but I was forced to 
stick with it for a while and now kinda am ok. I just hope it 
hasn't ruined my aptitude at PD controls! Perfect Dark is still 
the best shooter ever.).

But still, it isn't that big of a deal, my way works very well 
99.9% of the time.


> Probably not surprising that I avoid trying to code on anything 
> but a full-size keyboard with a proper section of <arrows, del,
> home, end, pgup, pgdn>, because coding on, say, a laptop
> keyboard (even one with a numpad) is a huge slowdown.

Yeah, I spend some time on a laptop (a little 12" one too) and it 
isn't as nice as the real keyboard, but I got one with a decent 
key placement and remapped some of the keys to fit the muscle 
memory anyway, so it isn't that bad.

The worst thing about my laptop keyboard is the 9 key doesn't 
work right and needs extra force. Since that's also (, ugh! But 
I'm cheap so whatever.

> Heh, actually, case in point, take a look at my normal work 
> setup:

lol, I got one of those ipads as a gift last year. I found it 
totally useless except for the angry birds and watching some 
video streams, i.e. not work at all.

But, I wanted a computer in my other room last week. My laptop is 
never at home, so I looked into buying something.

And my decision was sure to be painful to Steve Jobs: I bought an 
off brand usb thingy for the pad, and a full sized (Microsoft 
brand LOL) keyboard. Combined with an ssh app for the pad thingy 
(death to lowercase i), it became almost useful.

So I was only in for $20 and now have a halfway usable portable 
computer. No mouse though. Yes arrow keys (thank god, the morons 
at Apple refuse to put them in, which makes this thing utterly 
useless for anything other than their small set of sanctioned 
activities. OK, that apparently serves millions of people and 
turns an enormous profit, but that doesn't matter to /me/!). But, 
surprisingly, no to home and end!

Maybe it is just mapped wrong though, I haven't looked into the 
details.


Still though, 3/4 of a real keyboard is lightyears beyond the 
touch nonsense, and the price for the hack beat the crap out of 
buying a real computer.

> Geez, we still don't have that?

We spend too much time arguing over optional parenthesis!
January 24, 2013
Re: Make dur a property?
On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
Alexandrescu wrote:
> We need a good DIP on this. UFCS has destroyed all arguments in 
> favor of requiring parens. There is no question we must do 
> this. Anyone inclined toward writing a detailed DIP?
>

Let me strongly disagree. Language feature should never be 
introduced where library solution is possible.

And library solution is possible. And opDispatch makes it 
possible.
January 24, 2013
Re: Make dur a property?
On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
> On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
> Alexandrescu wrote:
>> We need a good DIP on this. UFCS has destroyed all arguments 
>> in favor of requiring parens. There is no question we must do 
>> this. Anyone inclined toward writing a detailed DIP?
>>
>
> Let me strongly disagree. Language feature should never be 
> introduced where library solution is possible.
>

C has strings as a concept and C++ as a library solution. Which 
strings are better: C, C++ or D?
January 24, 2013
Re: Make dur a property?
On Thursday, 24 January 2013 at 14:53:49 UTC, Maxim Fomin wrote:
> On Thursday, 24 January 2013 at 14:25:18 UTC, deadalnix wrote:
>> On Wednesday, 23 January 2013 at 23:39:50 UTC, Andrei 
>> Alexandrescu wrote:
>>> We need a good DIP on this. UFCS has destroyed all arguments 
>>> in favor of requiring parens. There is no question we must do 
>>> this. Anyone inclined toward writing a detailed DIP?
>>>
>>
>> Let me strongly disagree. Language feature should never be 
>> introduced where library solution is possible.
>>
>
> C has strings as a concept and C++ as a library solution. Which 
> strings are better: C, C++ or D?

D string string is not builtin. string is merely a thing in D.

D have builtin slices, which is a generic feature that is used 
with whatever you want.
5 6 7 8 9 10 11 12 13
Top | Discussion index | About this forum | D home