Too much riffle-raffle for the gain you mention (imo).
On Friday, July 22, 2016 at 1:01:42 PM UTC-4, Zhong Pan wrote:
>
> Most people coming from the object-oriented programming (OOP) world are
> used to using "." to access member methods/functions of a class. Consider
> the following simple example in Python that defines a class AA which has
> two members: an integer variable N to store the number of people attended,
> and a split(cost) function to calculate the cost split evenly among all
> attendees.
> class AA:
> def __init__(self, n):
> self.N = n
>
> def split(self, cost):
> return float(cost) / self.N
>
> groupdinner = AA(20)
> totalcost = 500.00
> print("{:d} people attended the group dinner, and each should pay
> ${:.2f}".format(groupdinner.N,
>
> groupdinner.split(totalcost)))
>
> Running the above code gives:
> 20 people attended the group dinner, and each should pay $25.00
>
> In Julia, with multiple dispatch and functions as first-class objects, the
> code would usually be written this way:
> type AA
> N :: Int
> end
>
> split(event::AA, x::Number) = x/event.N
>
> groupdinner = AA(20)
> totalcost = 500.00
> @printf("%d people attended the group dinner, and each should pay
> \$%.2f\n", groupdinner.N, split(groupdinner, totalcost))
>
> However, if someone insists that a class (or type in Julia) should "own"
> the member functions, I do see a workaround using inner constructor, like
> this:
> type AA
> N :: Int
> split :: Function
>
> AA(n::Int) = new(n, (x::Number) -> x/n)
> end
>
> groupdinner = AA(20)
> totalcost = 500.00
> @printf("%d people attended the group dinner, and each should pay
> \$%.2f\n", groupdinner.N, groupdinner.split(totalcost))
>
> This approach treats member functions as Function objects owned by a type,
> and the implementations of member functions are actually written in an
> inner constructor.
>
> Obviously this is a workaround and workarounds are awkward. However, I do
> see one potential practical use: modern IDEs often provide intellisense
> which will display an object's members once "." is typed after an object
> name. It's quite handy when I want to use a mature 3rd party module that I
> don't have time to learn by reading documentation; instead I just want to
> quickly try and use it by exploring the class hierarchy. It also saves a
> lot of memorizing/typing when I can be constantly reminded/auto-completed
> of matching variable/function names filtered by the object before the "."
> and the first few letters I typed in after the ".".
>
> In Julia one can use methods(AA) to display all functions that take AA
> object(s) as input(s). However, the list produced is often quite long and
> hard to read, since multiple dispatch will create many versions of the same
> function, with each differing only in the parameter types, and "methods"
> will show all of them with parameter types but no meaningful names. Also
> not sure how intellisense can help here. So the only way to explore for now
> is to know the function name (or at least a significant leading part of the
> name) and read its documentation by using "?" in a terminal, separate from
> the source code editor.
>
> With the "." workaround shown above intellisense should be able to prompt
> the name "split" alongside with "N".
>
> I just wonder if this workaround would be considered way too "unJulian"
> that it ought to be denounced. :-)
>
> Thanks,
> -Zhong
>
>
>
>
>
>
>
>
>
>
>
>
>
