Julia: Rename typeof() to type() for 2.0?

[CameronBieganek]

Since the type keyword was deprecated in favor of struct, can we rename typeof() to type() in Julia 2.0?

[StefanKarpinski]

We could, but typeof seems more explicit—it returns the type of the argument after all.

[CameronBieganek]

That argument implies that we should add of to the end of other function names:

length  ->  lengthof
size    ->  sizeof
first   ->  firstof
last    ->  lastof

I think the of part is usually implicit in accessor function names.

(Of course we already have both size and sizeof, but that's another matter.)

[JeffBezanson]

One reason is that typeof and sizeof are taken directly from C. But a better reason is that type is very useful as a variable name, keyword argument name, etc. so we do not want to "steal" it.

[CameronBieganek]

But a better reason is that type is very useful as a variable name, keyword argument name, etc. so we do not want to "steal" it.

Fair point. Though I've often wanted to use length and size as variable names.

[JeffBezanson]

Also a fair point. FWIW I don't really like the current size; I think shape or dims would be better. Of course that just steals different short words, but perhaps better ones.

Another consideration is that typeof is pretty rarely used compared to length, so it's less bad for it to have an ugly name. The precedent from C and other languages seals the deal. Maybe it's arbitrary, but to me lengthof just seems horrible while typeof is tolerable. Part of it might be that type is a very overloaded, ambiguous word (it's also a verb), so uses of it always seem to benefit from a qualifier, while there is really only one thing length(x) could mean.

[CameronBieganek]

Part of it might be that type is a very overloaded, ambiguous word (it's also a verb), so uses of it always seem to benefit from a qualifier, while there is really only one thing length(x) could mean.

I think this argument makes a lot of sense. For the record, I don't mind typeof, I was just wondering what other people thought about it.

[o314]

Curiously both sizeof and size exist today. Shouldn't they be merge ?

nameof is present too. no name but a names function exist too.
the pair nameof / names may seem a little bit strange.

Also a fair point. FWIW I don't really like the current size; I think shape or dims would be better. Of course that just steals different short words, but perhaps better ones.

Agree with that. IteratorSize and SizeUnknown may be better once renamed to IteratorShape / ShapeUnknown My preference go to IteratorDimension or HasDimension / dims rather than IteratorSize, HasShape, SizeUnknown, size. Missing may be use instead of the unknown pattern.

[brenhinkeller]

This would be immensely breaking, and would not enable any new functionality

[ChuckNielsen]

What about the ML aspect of it? It's barely been scratched.

On Thu, May 14, 2020, 6:27 PM Olivier MATHIEU [e-mail]
wrote:

Curiously both sizeof and size exist today. Shouldn't they be merge ?

nameof is present too. no name but a names function exist too.
the pair nameof / names may seem a little bit strange.

Also a fair point. FWIW I don't really like the current size; I think
shape or dims would be better. Of course that just steals different short
words, but perhaps better ones.

Agree with that. IteratorSize and SizeUnknown may be better once renamed
to IteratorShape / ShapeUnknown My preference go to IteratorDimension or
HasDimension / dims rather than IteratorSize, HasShape, SizeUnknown, size.
Missing may be use instead of the unknown pattern.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35808#issuecomment-628955326,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANERFEJQSCCDFSR4GMBSD4DRRSD67ANCNFSM4M4I5RIQ
.

[ChuckNielsen]

The space saved from the filename capute at time of retrieval. Like the
extra wordings are the only difference taking less overall space.

On Sun, Jun 14, 2020, 4:18 PM Chuck Nielsen [e-mail] wrote:

What about the ML aspect of it? It's barely been scratched.

On Thu, May 14, 2020, 6:27 PM Olivier MATHIEU [e-mail]
wrote:

Curiously both sizeof and size exist today. Shouldn't they be merge ?

nameof is present too. no name but a names function exist too.
the pair nameof / names may seem a little bit strange.

Also a fair point. FWIW I don't really like the current size; I think
shape or dims would be better. Of course that just steals different short
words, but perhaps better ones.

Agree with that. IteratorSize and SizeUnknown may be better once renamed
to IteratorShape / ShapeUnknown My preference go to IteratorDimension or
HasDimension / dims rather than IteratorSize, HasShape, SizeUnknown, size.
Missing may be use instead of the unknown pattern.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/JuliaLang/julia/issues/35808#issuecomment-628955326,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANERFEJQSCCDFSR4GMBSD4DRRSD67ANCNFSM4M4I5RIQ
.

[AzamatB]

Just to chime in on the topic of size, we have size and reshape, which is not nice. I think it should either be size and resize or shape and reshape.

[KDr2]

Just to chime in on the topic of size, we have size and reshape, which is not nice. I think it should either be size and resize or shape and reshape.

Why not (size and size!) or (shape and shape!) 😏

[MasonProtter]

Also a fair point. FWIW I don't really like the current size; I think shape or dims would be better. Of course that just steals different short words, but perhaps better ones.

I agree and think size is really unfortunate, especially because sizeof means something completely different:

julia> size(rand(5,5,5))
(5, 5, 5)

julia> sizeof(rand(5,5,5))
1000

It may just be to late to be worth the chaos caused by changing a core API like size but it's something that should be thought of.

---

Edit: Here's a pre-1.0 discussion: https://github.com/JuliaLang/julia/issues/22665 if it was decided that it wasn't worth changing before 1.0, it's way less likely to be worth changing post-1.0.

[mbauman]

The size/shape discussion is #22665.

[o314]

1/ a certain list of name seems to be reserved to avoid collision (shadowing) and keep them available for everyone design in everyday situation. this seems to be a good intention / practice. This may be helpful however to give an authoritative list somewhere

• typeof function - type remains available elsewhere
• nameof function - name remains available elsewhere

what about

• valueof function - value remains available elsewhere (currently not reserved, neither value)
• parentof function - parent remains available elsewhere (currently parent is reserved but not exported from Base)
• idof function
• argsof function
• sigof function
• bodyof function
• constructorof function !?

2/ it may help to be a little more precise about where collision can occur : on global var, on local var, on function argname, on struct argname e.g on which pair of them.

• a classical is a function that becomes unreachable with a local var.
  but renaming a local var costs nothing and ihmo is a no point.
• struct argname will go thru dot syntax / getfield call, should not be affected.
• a legitimate classical is to allow some function argname to use one of those hot word, rather than give it only to a function. so
  name_precedence(function_arg_name) > name_precedence(function_name)

etc. a summary table may be useful

3/ having both size and sizeof do not make sense. work have to be done on size/shape IteratorSize ... see you there @ 22665 :)

[brenhinkeller]

size and sizeof do significantly different things, in ways that are entirely consistent with their current names