user-pic

Damian Conway

  • Commented on A (not so) simple matter of privacy
    I think the only positive point for that syntax is that it is available! The $obj->&private_method() syntax has a few more benefits than just being available. For a start, it is analogous to the existing $obj->$subref() syntax. Which, incidentally,...
  • Commented on A (not so) simple matter of privacy
    [Note: I have received feedback that this discussion has been a little confusing to some readers, because in the Corinna proposal “slots” have now been renamed to “fields”, and the slot keyword is now field as well. I’ll attempt...
  • Commented on A (not so) simple matter of privacy
    Oh, no, it is not that simple! The right think to do there is to call A::foo on $b as $b is of class A too. You see, that’s exactly the problem with private methods. Your “right” behaviour can’t...
  • Commented on A (not so) simple matter of privacy
    I see them as different constructs but their interface and behaviors are so similar, that the same syntax can be used for both. And, to me, when two constructs are very similar but still distinct that’s precisely when you...
  • Commented on A (not so) simple matter of privacy
    I still fail to see why it is important to differentiate sub/method calls **inside** a class...but it is ok to use the same syntax for lexicals/slots... Because sub calls and method calls are different constructs with different interfaces and...
  • Commented on A (not so) simple matter of privacy
    IIRC, perl does subroutine look up at compile time*. No, subs are always looked up at runtime (unless, of course, you’re calling them in a BEGIN, CHECK, UNITCHECK, INIT, or END block). It has to be runtime because Perl...
  • Commented on A (not so) simple matter of privacy
    I do understand your point, Salvador. I just don’t agree it’s the right way to go. :-) If methods can be called like subs, then every sub call now also has to check whether there's a suitable method to call...
  • Commented on A (not so) simple matter of privacy
    Salvador asked: Couldn't lexical subs be extended to just work as private methods too... If they’re not methods, they wouldn’t (and shouldn’t!) have a $self variable. Which means, as you later suggested, that we’re back to: my method _print_x ()...
  • Commented on A (not so) simple matter of privacy
    Flavio wondered: ...why we can't keep the interface and the implementation separate. I’m certainly in favour that too! But, as you point out, this clean, safe, and simple approach that we both prefer does have a non-trivial cost: it requires...
  • Commented on A (not so) simple matter of privacy
    Ovid explained: I had actually objected to this: croak "Can't call method" if caller ne __CLASS__; That's because in my calling code, I could do this: { package Class::Im::Using; $object->private_method; } My understanding — or perhaps just my fervent wish — was that package...
  • Commented on A (not so) simple matter of privacy
    My apologies if I misunderstood your email and misattributed the  method $foo () {...}  syntax to the PSC. I’ve now corrected that in the post. And, yes, it’s true that no OO system prevents author wickedness, but we can still...
  • Posted A (not so) simple matter of privacy to Damian Conway

    You may have seen Ovid's recent post about moving forward with implementing an initial subset of the Cori…

  • Posted Vale, David to Damian Conway

    David H. Adler passed away yesterday.

    David was a gentleman and a scholar: a gentle, warm, erudite, funny, clever, and deeply kind man. And one who has made a vast cont…

  • Commented on A dream resyntaxed
    Rather than respond individually to Matt’s many valid points — and his graceful concessions — let me simply summarize my current opinion. I concede that my sub is at this point a well established prior art for prefix declaration modifiers...
  • Commented on A dream resyntaxed
    The previous discussions on IRC and github were never about "there should never be a specific syntax for class data", they were always about "this specific syntax for class data is going to make 'slot' even weirder than it...
  • Commented on A dream resyntaxed
    Thanks for the feedback, Jakub. And, I agree. The attribute versions don't read as naturally. But that's not because the attribute version is "weird"; it's because the attribute names haven't (yet!) been adjusted to reflect the changed location of the...
  • Commented on A dream resyntaxed
    Hi Matt. Thanks so much for your thoughtful and detailed response, and especially for the pointer to previous discussions on this subject. And I agree that, if methods weren't BEGIN-lifted, my would be (technically) sufficient for class data. But can...
  • Posted A dream resyntaxed to Damian Conway

    [Author’s note: If you’ve read Curtis Poe’s most recent ="h…

  • Commented on A dream realized
    I'm a little confused, Philip. You ask me to rewrite the article so that you can "know the compelling reasons why Corinna is so good"...but the article already contains at least six of those: More concise syntax (therefore more readable)...
  • Posted A dream realized to Damian Conway

    Have you heard that they are finally putting together a proposal to add a clean modern OO system into the core of Perl?

    If you haven’t, I strongly encourage you to look over the RFC for Corinna, or at least watch Ovid’s ="https://www.you…

  • Posted Coders In Cars Getting Chatty to Damian Conway

    The last time I spoke at Craft Conference, I also took part in what is probably the most fun and unusual interview of my career: Ivette Ördög’s Morning Commute.

    Bear in mind, howev…

  • Posted An existential threat (that <em>isn't</em> COVID-19) to Damian Conway

    Many of you will know my good friend Peter Scott as a Perl luminary. More recently he has turned his attention and his considerable talents to focus on the future of AI, both as an unprecedented opportunity for our society...and as an unprecedented threat to our species.

    A few years back, …

  • Posted Springtime in Switzerland to Damian Conway

    For over a decade now, I've been running public training classes in both presentation skills
    the University of Lausanne, and the École Polytechnique Fédérale de Lausanne.

    This year, in the week…

  • Posted <code>Itch.scratch()</code> to Damian Conway

    .CODE_ALT_A {
        line-height: 130%;
        color:       Crimson;
    }
    
    .CODE_ALT_B {
        line-height: 130%;
        color:       MediumBlue;
    }
    
    .CODE_ALT_C {
        l…
  • Commented on Coding with a full toolset
    One does still need ».Str But it can be written as a (60% shorter) prefix operator: ~«...
  • Posted To compute a constant of calculus</br><small>(A treatise on multiple ways)</small> to Damian Conway

  • Posted With friends like these... to Damian Conway

    C-o-rr-a-ll-i-n-g d-i-tt-o-e-d l-e-tt-e-r-s

    I was going to focus this week on the first task of the 20th Weekly Challenge...but what can I say? The task was a break a string specified on t…

  • Commented on Infinite work is less work
    A prime that is equal to the mean of its two neighbour primes is not "weak", but "balanced". The challenge task did not request those, but they would have been trivial to add: sub balanced (\n) { n > 0...
  • Posted Greed is good, balance is better, beauty is best. to Damian Conway

    Avidis, avidus natura parum est

    One of my first forays into Perl programming, 20 years ago now, was a tool that takes a piece of plaintext, analyzes its structure, and formats it neatly for a given line width. It’s a mode…

  • Posted Chopping substrings to Damian Conway

    The first task of the was to find the longest common substring(s) in a set of strings. That is, given a set of strings like “ABABC”, “BABCA” and “ABCBA”, print out “ABC”.

    The…

Subscribe to feed Recent Actions from Damian Conway

  • Salvador Fandiño commented on A (not so) simple matter of privacy
    quite a bit trickier. The implementors might not be willing — or even able — to do so.

    Yes, and there are other issues. AFAIK, supporting class methods is planned (tagging then with :common) and lexical subs should be callable from those, and that creates several edge cases that could be quite difficult to support.

    class A {
      field $a :common;
      field $b;
      my sub priv {
        eval '$a + 1'; # which fields are visible from this eval?
                       # depends …
  • Aristotle commented on A (not so) simple matter of privacy
    # which fields are visible from this eval?

    Isn’t the answer simply “none”? It seems a trick question. Fields aren’t visible inside a sub, whether it’s lexical or not, no?

  • Salvador Fandiño commented on A (not so) simple matter of privacy

    Isn’t the answer simply “none”?

    Yes, that was the conclusion: it is not a good idea to let lexical subroutines, declared at the class top level, access the object fields.

    It seems a trick question. Fields aren’t visible inside a sub, whether it’s lexical or not, no?

    Well, IMO, they should be visible if the sub is declared inside a method. For instance, I would expect the following code to work:

    use Scalar::Util qw(first);
    
    

    class A {
    field $…

  • Aristotle commented on A (not so) simple matter of privacy
    I would expect the following code to work:

    Well, yes, obviously, a closure is a different kind of situation. The question would be what happens in a named sub declared inside a method – where I would expect the exact same behaviour that the “variable will not stay shared” warning cautions against currently. And I would expect the use of a lexical sub to cure the problem, the same way it currently does for regular subs.

  • Toby Inkster commented on A (not so) simple matter of privacy
    method $do_internal () {
      ...;
    }
    

    has been supported by Zydeco for over a year. documentation.

Subscribe to feed Responses to Comments from Damian Conway

About blogs.perl.org

blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.