mugwump

• Website: sam.vilain.net/
• About: Perl hacker and systems architect working for Catalyst IT, New Zealand. Author of Net::SSLeay::OO, Date::Holidays::NZ, and other works.

Recent Actions

• Commented on My take on Modern Perl
  Far better than duck typing (at least as implemented in most languages) is what happens using, eg templates in C++. Because C++ is compiling, it will expand out those types in all the functions where they are used - and...
• Commented on What should be core in Perl 5.16?
  This really shouldn't be a popularity contest for a set of recommended modules. Modules should have a clear reason to be in core. eg, they provide common functionality that CPAN modules should be standardizing on. They should be fixing core...

Comment Threads

• lajandy commented on What should be core in Perl 5.16?

  My knee-jerk reaction is "no more stuff in the core!" Core Perl 5 is already getting bloated to the point *nix distributors are considering removing it from default installs. But after reading over others' comments, I do think there are a few additions that merit discussion. Most importantly, adding some form of try/catch block ala Try::Tiny should be discussed, especially if it could be augmented by a basic exception class like Exception::Simple. The eval exception handling syntax is just too crufty and awkward to use. Just about all modern languages have some type of built-in…

• Clayton Scott commented on What should be core in Perl 5.16?

  Ctypes!

  
  There are a large number of tools I'd like to use that have C client libraries and since my C is weak and my XS is weaker having ctypes in core would be quite awesome.

  
  http://gitorious.org/perl-ctypes/perl-ctypes

  
  But I would happily settle for it to be on CPAN.

  
  PS Thank you Reini Urban for picking up and running with the project.
  

• educated_foo commented on What should be core in Perl 5.16?

  Ctypes is great in that it doesn't need a compiler, but using mutant pack codes for function prototypes seems like a bad idea. I would rather see something that parsed (a subset of) C function prototypes. Even more awesome would be something that demangled and parsed C++ function names to get the prototypes automatically.

• Reini Urban commented on My take on Modern Perl

  LeoNerd: You still haven't got it.

  I will provide *optional* ways to cut off generic types.

  The user or library author can decide by themselves that certain data will be typed. And get safety, speed and less size for it. There is no need everything must be generic, there should be a way to enable programmers to restrict their data.
  You leave the type off, and then you can overload or tie or upgrade it to your wish.

  In lisp this optional typing is done with "(the type what)" http://www.cs.cmu.…

• David Nichols commented on My take on Modern Perl

  Reini, could you please tell me what channels are in this context (the technical idea behind this concept)?

  Qore uses lightweight web service protocols for communication - different from IPC because the 2 communicating parties don't have to be on the same system. One big drawback is that so far I don't have any way of serializing objects over these protocols. The protocols supported so far are XML-RPC, JSON-RPC, and, by far my favorite, proprietary YAML-RPC (because AFAIK there is no real standard for this yet).

  In a single process, threads will typically use Queue objects …