define a convert method or a constructor?

[Douglas Bates]

In extras/linalg_suitesparse.jl I have defined several types to wrap pointers to structs defined in the CHOLMOD code (in deps/SuiteSparse-4.0.0).  Currently I have convert methods to change from one type to another, e.g. from a sparse Cholesky factor to a sparse matrix.  I am beginning to think that it would be better to instead define constructors for the target type taking an object of the origin type.  So instead of writing

convert(CholmodSparseOut{Float64,Int64}, L)

where L is a CholmodFactor{Float64,Int64} object, I could just write

CholmodSparseOut(L)

I guess my general question is whether there would be a purpose in writing a convert method instead of a constructor.

[Stefan Karpinski]

This is a bit muddled at the moment and Jeff and I have discussed this very issue a lot. The current answer is that convert is what you want here. Constructors are really for making composites out of pieces. That's why the function for turning things into Ints are called int() lowercase and not Int() uppercase: it's not a constructor because you're not putting an Int together from components.

However, this seems to be a bit confusing. People want to write Int(1.5) and explaining why it's int(1.5) instead is kind of hard and leaves everyone a little unsatisfied. So maybe T(x) should just be how you convert things or construct things. But I'm not super thrilled about that because sometimes conversion and construction aren't exactly the same thing. Tough call. 

[John Myles White]

A formal distinction between conversion and construction seems potentially worth keeping (and might be valuable for many reasons I don't properly appreciate), but it's not clear to me whether it's going to become first nature to most people. I suspect that for many people, their first pass interpretation of the constructor call, ObjectType(x), is that this function is how you build an "ObjectType" out of an "x". From that perspective, it almost sounds like the distinction between converters and constructors is that converters are 1-ary, while constructors are n-ary. In that case, using the same uppercase conversion seems helpful, even if the semantics for the 1-ary and n-ary cases are distinct.

As for one person's evidence of ongoing confusion, I do continue to be surprised that it's int() and not Int() we use to convert a Float to an Int.

 -- John

[John Cowan]

On Fri, Jul 13, 2012 at 7:16 PM, John Myles White
<johnmyl...@gmail.com> wrote:

> A formal distinction between conversion and construction seems potentially
> worth keeping (and might be valuable for many reasons I don't properly
> appreciate), but it's not clear to me whether it's going to become first
> nature to most people.

I think the distinction is entirely artificial and should be
abolished. Consider a case in which only one argument is needed for
construction: e.g. a constructor that turns a ISO 8601 string into a
Date object. This could equally well be seen as a converter from
String to Date. The difference between an Int and and Date is just
implementational -- Int is a bits type and Date is a composite type.
In either case you are generating a new value.

So I'd like to see int() changed to Int().

--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures

[Andrei de Araújo Formiga]

2012/7/13 John Cowan <johnw...@gmail.com>:

> On Fri, Jul 13, 2012 at 7:16 PM, John Myles White
> <johnmyl...@gmail.com> wrote:
>
>> A formal distinction between conversion and construction seems potentially
>> worth keeping (and might be valuable for many reasons I don't properly
>> appreciate), but it's not clear to me whether it's going to become first
>> nature to most people.
>
> I think the distinction is entirely artificial and should be
> abolished. Consider a case in which only one argument is needed for
> construction: e.g. a constructor that turns a ISO 8601 string into a
> Date object. This could equally well be seen as a converter from
> String to Date. The difference between an Int and and Date is just
> implementational -- Int is a bits type and Date is a composite type.
> In either case you are generating a new value.
>

To give my proverbial 2 cents here, I agree with the above.
Constructors build a new object from 0 or more existing object.
Conversion is construction, and distinguishing between the two can
only be done by artificial impositions, or convention.

[Jeffrey Sarnoff]

I prefer Julia with type names Capitalized and that Capitalized name be applied to obtain anew a so-typed object. 
The persistence of type token relevance expresses type as an identifying conduit and at once identifies the same.

Typealias should be aliasing a type identifier and that alias qua token should be callable aliasing  type instantiation/construction/generation/conversion.
typealias should alias type identification and also be as a token identical multidispatched type constructor-- afaik  this does happen with Composite Types.

Bitstypes + converters/composers + aliases should participate: NameOfType as name and naming (name-as-identifier+associator, naming-as-instantiating).