Hi Gabriel, 

If you're types often have default values you may want to take a look 
Parameters.jl <https://github.com/mauro3/Parameters.jl> for a neat and 
useful implementation of types with default values.

As for the Bar() constructor, is may be odd for future people looking at 
your code to have a constructor like method that doesn't correspond to a 
type. 

-Nathan

On Tuesday, 21 June 2016 14:49:40 UTC-4, Gabriel Gellner wrote:
>
> Ugh keyboard error.
>
> So lets say I have the type
>
> type Foo
>     field1
>     field2
> end
>
> So I have my nice constructors dealing with all the ways I want to create 
> Foo types, but then I want a specialized Foo that has field2 set to some 
> special value that has a special sub meaning from my default Foo. Say I 
> have a default constructor for Foo like
>
> Foo(;field1=<default>, field2=<default>)
>
> But I want to have a different default, so I call this
> Bar(;field1=<default>, field2=<new default>) = Foo(field1, field2)
>
> My question! Really this is an abuse of the naming guide, as Bar is really 
> a method, not a type constructor with the same name as the type, but I 
> guess I am thinking about this as a kind of specialized type of Foo, hence 
> the uppercase, but should I instead do
>
> bar(...)
>
> when I am returning these kind of specialized versions of Foo?
>
> On Tuesday, June 21, 2016 at 11:44:07 AM UTC-7, Gabriel Gellner wrote:
>>
>> So going deeper into using my own types, and coding style in julia.
>>
>> Lets say I have the container type
>>
>> type Foo
>>
>>
>> On Monday, June 20, 2016 at 7:10:15 AM UTC-7, Gabriel Gellner wrote:
>>>
>>> That was what I was feeling. That this was a legacy issue for lowercase 
>>> type "constructors". Thanks so much.
>>>
>>> On Monday, June 20, 2016 at 1:11:41 AM UTC-7, Mauro wrote:
>>>>
>>>> I think you should use the constructors if the user expects to 
>>>> construct 
>>>> a certain type, e.g. `Dict()`.  Conversely if the user cares about the 
>>>> action then use a function, e.g.: 
>>>>
>>>> julia> keys(Dict()) 
>>>> Base.KeyIterator for a Dict{Any,Any} with 0 entries 
>>>>
>>>> here I don't care about the type, I just want to iterate the keys. 
>>>>
>>>> But of course, it's not that clear-cut: `linspace` has history, so does 
>>>> `zeros`.  So, for a new container type I'd use the constructor 
>>>> `FooBar`. 
>>>>
>>>> On Sun, 2016-06-19 at 23:12, Gabriel Gellner <gabriel...@gmail.com> 
>>>> wrote: 
>>>> > I am currently making some container like types, so I am using the 
>>>> > convention of studly caps for  the types ie `FooBar`. For usage I am 
>>>> > confused on what the julian convention is for having expressive type 
>>>> > constructors like for `Dict` and `DataFrame`, versus using methods 
>>>> like 
>>>> > `linspace`. Clearly I could use either, but it is not clear to me 
>>>> when I 
>>>> > should use one convention over the other. 
>>>> > 
>>>> > Clearly I can have my api be like: 
>>>> > 
>>>> > f = FooBar(...) 
>>>> > 
>>>> > or 
>>>> > 
>>>> > f = foobar() 
>>>> > 
>>>> > but is one preferred over the other? Is it just random when to use 
>>>> one or 
>>>> > the other when making container like types? 
>>>>
>>>

Reply via email to