develooper Front page | perl.perl5.porters | Postings from February 2015

Re: Name those functions!

Thread Previous | Thread Next
Karl Williamson
February 11, 2015 22:08
Re: Name those functions!
Message ID:
On 01/23/2015 04:24 PM, Aristotle Pagaltzis wrote:
> * Karl Williamson <> [2015-01-22 20:00]:
>> One is like charinfo, but returns the value for all possible Unicode
>> properties. charinfo takes a code point argument and returns the value
>> for some prominent properties in a hash. It would slow it way down to
>> have it by default put the values for all properties in the hash. One
>> solution would be to have an optional second argument that, if it
>> evaluates to true, adds the missing properties to the hash. Or it could
>> be an entirely new function. What is your opnion?

I've just now gotten around to looking at it more closely.  And it turns 
out I misled people.  The values the new function returns in many cases 
are different from what charinfo does.  charinfo avoids returning UTF-8. 
  So, for example, using an ASCII example for convenience, it will 
return "0053 0083" to mean "Ss", and so the caller has to munge things 
around in many cases to get something usable (though certainly there are 
uses for the current API).

The new function returns the actual string.

So I'm thinking that a flag argument would not be appropriate, nor would 
a name that contains 'charinfo', as the two functions have enough 
differences, that this would be confusing.

> On the function vs arg front I see two main concerns.
> One is how likely it is for code which uses this function to need to be
> able to go both ways. That requires a flag somewhere at minimum. In the
> case of an extra argument, the flag is *all* it takes whereas in the
> case of two different functions, you need extra machinery on top of it:
> either duplicating the call in a ternary, or fiddling with coderefs.
> The other concern is how much code would have to be duplicated between
> the functions. If duplication is low but one function is just a façade
> for the other, or they both call an internal function, the question is
> why not expose the single-function API directly. If there is duplication
> despite one function just being a façade for the other, which sometimes
> happens, then the same question has even more emphasis.
> Basically, if you look at the holistic complexity of caller and callee
> as a whole, which option makes more sense?
> (There are other possible questions, e.g. the future evolution of the
> interface, like what happens if the desire arises for the function to
> allow additional parametrisation. It does not feel to me like this is
> a prominent concern in this case.)
>> If you want a new function, please think of a name for it. Some ideas are:
>> charprops($codepoint)
>> all_charprops($codepoint)
> If it’s two different functions I think I would call the whole-shebang
> one `charinfo_full`. IMO that makes it immediately clear what the new
> function does (i.e. expects the same arguments and returns the same kind
> of thing as `charinfo`) and how the two relate to each other (i.e. one
> of them omits some things and the other gives you the whole shebang).

Given what I've said above, I'm tentatively calling it 'charprops_all'
>> The other function takes 2 arguments: a property and a code point, and
>> returns the value of that property for that code point.
>> charprop($codepoint, $property)
>> charprop($property, $codepoint)
>> charprop_value(...)
>> Ideas please.
> I think `charprop($codepoint, $property)` is just fine.


> The other order of arguments doesn’t make sense to me. This is a lookup
> operation where the codepoint refers to a key/value set i.e. essentially
> a hash, and you would naturally write $codepoint{$property} if it were
> realised as such.
> As for tacking on `_values` – property values are immutable and I’m not
> aware of a property on one codepoint vs the same property on another one
> having any distinguishing features beyond their values. That means it’s
> redundant to specify that you refer to the value of the property since
> you’re never going to mean anything else when you refer to it.
> Regards,

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About