Hacker News Reader

Comment by StefanKarpinski | Hacker News Reader

As sibling posts have pointed out, you can do all of those things:

1. You can trivially write a `getproperty` method for a tuple. It is considered to be type piracy and thus runs the risk of colliding with someone else's definition, but the language absolutely lets you do it.

2. You can broadcast over the fields of a `NamedTuple` by defining appropriate methods. Again, it's type piracy, so take that into consideration, but the language lets you do this easily as well.

3. The https://github.com/JuliaArrays/PaddedViews.jl package implements exactly what you're saying Julia won't let you do.

If anything, Julia errs on the side of allowing you to do too many things! There are very few things the language really won't let you do.

View on HN

I meant literally this:

  julia> (x = 1, y = 2) .+ (x = 1, y = 2)

  ERROR: ArgumentError: broadcasting over dictionaries and `NamedTuple`s is reserved

This doesn't really seem like a legitimate complaint. You want some particular pet behaviour, and claim it is impossible to achieve. When someone points out that it is in fact possible, you are unhappy that someone else did not anticipate and implement it pre-emptively...

Do you also expect your 'custom getproperty' (whatever it might do) to have been predicted and pre-implemented by someone else? And do you also expect arrays to 'just know' what value or behaviour you are looking for whenever you index out of bounds?

Stefan's point was that you are free to commit type piracy and make this do whatever you want

  julia> Base.broadcasted(f, x::NamedTuple, y::NamedTuple) = "my custom method!"

  julia> (x=1, y=2) .+ (x=1, y=2)
  "my custom method!"

And as the phrase "reserved" in the error message indicates, it will likely be given a meaning once all the ramifications of doing so are worked out and the best choice of meaning is decided upon. If you're impatient and don't want to wait for that, define it to do what you want. Your code won't even break when it is given an official behavior since your method will overwrite the built-in one.

But this is exactly the kind of thing I called a bothersome corner case. Needing to redefine a global function in order to use fairly intuitive behavior is not great developer experience.

When things like this are left undefined, it's not to intentionally annoy you, as you seem to be taking it. It's generally because there are two or more reasonable possible behaviors and which one is correct hasn't yet been determined. In this particular case, there are subtleties because named tuples can be seen as ordered collections of values and as named associative structures. Deciding that kind of thing takes a lot of time and effort. If you feel that there is a preferred behavior that broadcasting over named tuples ought to have, it would be helpful to post that on GitHub.

Reply on news.ycombinator.com