Re: [julia-users] Syntax for composite type constructors

[Stephan Buchert]

Thanks, https://github.com/mauro3/Parameters.jl does of course what I want 
and more.

Re: [julia-users] Syntax for composite type constructors

[Mauro]

On Fri, 2016-06-17 at 18:19, Jacob Quinn  wrote:
> There's been a long-open issue for this here:
> https://github.com/JuliaLang/julia/pull/6122
>
> Not sure why it's never been implemented as I don't think anyone was really
> opposed. I imagine if people make a big push for it, we could convince
> someone to get it across the finish line.

Check out https://github.com/mauro3/Parameters.jl . It makes keyword
constructors as well as default values and other goodies.

> -Jacob
>
> On Fri, Jun 17, 2016 at 11:17 AM, Stephan Buchert 
> wrote:
>
>> When making instances of my composite Julia types, such as
>>
>> foo = Foo(1, "bartxt", 3.14)
>>
>> I often have to look up the definition, because I don't remember whether,
>> in this case, "bar" was the first or the second field:
>>
>> type Foo
>>   bar::AbstractString
>>   baz::Int
>>   qux::Float64
>> end
>>
>> "bar" was the first field, so the correct construction is
>>
>> foo = Foo("bartxt", 1, 3.14)
>>
>> In this case the first, incorrect code would not compile because of no
>> matching method.
>>
>> But for
>>
>> type Goo
>>   vertical::Float64
>>   horizontal::Float64
>>   qux::Float64
>> end
>>
>> it is easy to write incorrect code when the order of the fields gets mixed
>> up, and such bugs are potentially difficult to find.
>>
>> Wouldn't it be possible to allow (optionally) for a syntax like
>>
>> foo = Foo(;bar=bartxt, baz=1, qux=3.14);
>> goo = Goo(;horizontal=186.,vertical=0.33, qux=3.14)
>>
>> where the keyword arguments are the fieldnames of the type?
>>
>> Often I remember the fields of a type, but not their order.
>> With this syntax the argument order would be arbitrary.
>> The syntax would imply, that incorrect, non-existing, or missing
>> fields/keywords result in an error.
>>
>> Thanks for your consideration.
>>

Re: [julia-users] Syntax for composite type constructors

[Jacob Quinn]

There's been a long-open issue for this here:
https://github.com/JuliaLang/julia/pull/6122

Not sure why it's never been implemented as I don't think anyone was really
opposed. I imagine if people make a big push for it, we could convince
someone to get it across the finish line.

-Jacob

On Fri, Jun 17, 2016 at 11:17 AM, Stephan Buchert 
wrote:

> When making instances of my composite Julia types, such as
>
> foo = Foo(1, "bartxt", 3.14)
>
> I often have to look up the definition, because I don't remember whether,
> in this case, "bar" was the first or the second field:
>
> type Foo
>   bar::AbstractString
>   baz::Int
>   qux::Float64
> end
>
> "bar" was the first field, so the correct construction is
>
> foo = Foo("bartxt", 1, 3.14)
>
> In this case the first, incorrect code would not compile because of no
> matching method.
>
> But for
>
> type Goo
>   vertical::Float64
>   horizontal::Float64
>   qux::Float64
> end
>
> it is easy to write incorrect code when the order of the fields gets mixed
> up, and such bugs are potentially difficult to find.
>
> Wouldn't it be possible to allow (optionally) for a syntax like
>
> foo = Foo(;bar=bartxt, baz=1, qux=3.14);
> goo = Goo(;horizontal=186.,vertical=0.33, qux=3.14)
>
> where the keyword arguments are the fieldnames of the type?
>
> Often I remember the fields of a type, but not their order.
> With this syntax the argument order would be arbitrary.
> The syntax would imply, that incorrect, non-existing, or missing
> fields/keywords result in an error.
>
> Thanks for your consideration.
>

[julia-users] Syntax for composite type constructors

[Stephan Buchert]

When making instances of my composite Julia types, such as

foo = Foo(1, "bartxt", 3.14)

I often have to look up the definition, because I don't remember whether, 
in this case, "bar" was the first or the second field:

type Foo
  bar::AbstractString
  baz::Int
  qux::Float64
end

"bar" was the first field, so the correct construction is

foo = Foo("bartxt", 1, 3.14)

In this case the first, incorrect code would not compile because of no 
matching method.

But for

type Goo
  vertical::Float64
  horizontal::Float64
  qux::Float64
end

it is easy to write incorrect code when the order of the fields gets mixed 
up, and such bugs are potentially difficult to find.

Wouldn't it be possible to allow (optionally) for a syntax like

foo = Foo(;bar=bartxt, baz=1, qux=3.14);
goo = Goo(;horizontal=186.,vertical=0.33, qux=3.14)

where the keyword arguments are the fieldnames of the type?

Often I remember the fields of a type, but not their order.
With this syntax the argument order would be arbitrary.
The syntax would imply, that incorrect, non-existing, or missing 
fields/keywords result in an error.

Thanks for your consideration.