January 14, 2019 Re: Named constructors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 1/14/19 3:05 PM, Jacob Carlborg wrote:
> On 2019-01-14 15:31, aliak wrote:
>
>> Swift. Named arguments. Overloading. Executed perfectly IMO:
>
> Technically it's not function overloading. The functions have separate names, the parameter keys are part of the name. That's at least how it works in Objective-C.
>
I was going to say that, but I feel like possibliy in my dealings with Swift (which isn't huge), it may have had more abilities for overloading than objective-C.
-Steve
|
January 15, 2019 Re: Named constructors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Steven Schveighoffer | On Monday, 14 January 2019 at 20:59:11 UTC, Steven Schveighoffer wrote:
> On 1/14/19 3:05 PM, Jacob Carlborg wrote:
>> On 2019-01-14 15:31, aliak wrote:
>>
>>> Swift. Named arguments. Overloading. Executed perfectly IMO:
>>
>> Technically it's not function overloading. The functions have separate names, the parameter keys are part of the name. That's at least how it works in Objective-C.
>>
>
> I was going to say that, but I feel like possibliy in my dealings with Swift (which isn't huge), it may have had more abilities for overloading than objective-C.
>
> -Steve
You can use the same keys with different types and call the correct function based on argument type. You can even overload based on return type alone!
I don't remember if that was possible in objective-c or not - flushed from me system :p
|
January 15, 2019 Re: Named constructors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Monday, 14 January 2019 at 20:02:55 UTC, Jacob Carlborg wrote:
> On 2019-01-14 14:54, Atila Neves wrote:
>
>> I don't think that'd be useful for me. The only thing I care about is the latency between hitting a key and having feedback on my tests. It's rare that I have tests that would be significantly faster by optimising the machine code running on the CPU.
>
> I didn't mean to use a JIT to optimize the execution. I was more thinking of using LDC as a JIT to avoid having to implement your own interpreter. But the JIT might be too slow to compile the code.
>
> Hmm, can use use the CTFE interpreter in DMD? Hack that to use it for none CTFE stuff as well.
I tried that first - many of the declarations are private and it was a pain to reuse the code. Then I started writing an interpreter from scratch and realised very soon how much work that would be.
I need to try and reuse the existing code again. I'm also not sure how to deal with imported code from dependencies yet and am a bit in analysis paralysis.
|
January 15, 2019 Re: Named constructors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Atila Neves | On Monday, 14 January 2019 at 16:04:26 UTC, Atila Neves wrote:
> On Monday, 14 January 2019 at 14:31:09 UTC, aliak wrote:
>> auto a = Builder()
>> .accountNumber(202)
>> .firstName("Bob")
>> .lastName("Who")
>> .branch("N-2")
>> .interest(20.0)
>> .balance(10.0)
>> .build()
>>
>> ??
>
> auto a = Customer(AccountNumber(202),
> FirstName("Bob"),
> LastName("Who"),
> Branch("N-2"),
> Interest(20.0),
> Balance(10.0));
>
> struct Customer {
> this(A...)(auto ref A args) if(constraintVerifyingNumberAndTypesOfArgs!A) {
> this.accountNumber = args[staticIndexOf!(AccountNumber, A)];
> // etc.
> }
> }
I think these design patterns are useful if you really want named arguments in your code right now, but they really shouldn't replace the structure initialization DIP.
Personally speaking, I hate having hacks like these in my code and would immensely prefer an idiomatic syntax eg:
auto a = Customer{ accountNumber: 202, fistName: "Bob" };
which would produce easy-to-read error messages like:
Error: `fistName` is not a member of `Customer`. Did you mean `firstName`?
Error: Initialization list for `Customer` does not provide value for member variable `lastName`, which has no default value defined.
I'm having trouble guessing what error messages your Customer structure would provide, but I imagine they wouldn't be nearly as informative. Same thing for generated documentation.
|
January 15, 2019 Re: Named constructors | ||||
---|---|---|---|---|
| ||||
Posted in reply to Olivier FAURE | On Tuesday, 15 January 2019 at 12:42:32 UTC, Olivier FAURE wrote:
> On Monday, 14 January 2019 at 16:04:26 UTC, Atila Neves wrote:
>> [...]
>
> I think these design patterns are useful if you really want named arguments in your code right now, but they really shouldn't replace the structure initialization DIP.
>
> [...]
Good error messages are perfectly doable with a library solution. Sure, the "Did you mean" one is harder to implement, but still doable.
|
Copyright © 1999-2021 by the D Language Foundation