Re: [svn:perl6-synopsis] r14421 - doc/trunk/design/syn
On 6/14/07, Mark Overmeer [EMAIL PROTECTED] wrote:
I had suggested syntax like this, in Perl6:
class Mail::Message {
`base class for message types
.has $msgid;
`The (internet wide) unique string which identifies this
`message object. May be undef as long as the message is
`begin composed.
.has $content_type = 'text/plain';
}
I always thought this could be achieved using traits:
class Mail::Message is doc(base class for message types) {
.has $msgid is doc(The (internet wide) unique string which
identifies this message object. May be undef as long as the message
is begin composed.);
.has $content_type = 'text/plain';
}
--
Aankhen
(We have no branches.)
Re: POD - Code entanglement
On 6/14/07, Thomas Wittek [EMAIL PROTECTED] wrote: It's a bit like HTML-XML, where the former lacks most of the semantics and makes the information processing - not to speak about a consistent look over several documents - a lot harder. Actually, that's incorrect. HTML is a markup language with a particular set of elements, some of which have semantic meaning attached and some of which don't. XML, on the other hand, is a means of writing your own markup languages; this has two consequences in this context: 1. It is just as easy—if not easier—to have an XML dialect containing elements with absolutely no meaning. 2. Even if the dialect contains only elements with well-defined semantics, it's still completely meaningless to a generic XML parser. A parser must be intimately familiar with the dialect to understand that any element has semantic meaning. If you were referring to XHTML vs. HTML, I would like to point out that XHTML 1.0 is merely a reformulation of HTML 4.01 in XML. The elements and their semantics are unchanged. XHTML 1.1 modularizes the DTD and adds a few Ruby (annotation, obviously, not language) elements, in addition to a few other minor changes. As for XHTML 2.0, that's still a long way off. :-) -- Aankhen (We have no branches.)
Re: explicit line termination with ;: why?
On 5/14/07, Andrew Shitov [EMAIL PROTECTED] wrote: JavaScript allows to omit semicolumn. Speaking of JavaScript, any experienced JavaScript programmer will tell you that while semi-colons are in fact optional, you should always treat them as mandatory, to avoid subtle errors creeping into your code. -- Aankhen (We have no branches.)
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
On 9/21/06, Juerd [EMAIL PROTECTED] wrote: Because they speak the same language. That is: they know about arguments passed via forms, and the preferred output language (xhtml? html?). Ah, I didn't think of that. My bad. Roles for all these things sound great to me. :-) Aankhen
Re: Web development I: Web::Toolkit
On 9/19/06, A. Pagaltzis [EMAIL PROTECTED] wrote: * Aankhen [EMAIL PROTECTED] [2006-09-17 21:00]: XHTML 1.0 and 1.1 offer no practical benefits over HTML, but tangible disadvantages. To be fair, XHTML does let you embed MathML and SVG (as well as XForms, pending browser support) in your markup, which is a great boon where applicable. But that's the only benefit XHTML provides as of yet. Not XHTML 1.0 and XHTML 1.1... there you need to use the compound document types, e.g. XHTML + SVG + MathML. Since we're being fair, XHTML 1.1 also offers specific elements for Ruby[1]. If the XHTML produced by the module adheres to the W3C standard, there won't be any elements that only work in certain browsers (with the exception of abbr... no others I can think of offhand). Plenty. IE6 doesn't understand `q`, off the top of my head. I know there are several more, plus a few that *no* browser supports. On top of this, roughly 80% (or so it sometimes feels) of the useful attributes defined in HTML do not have any tangible browser support (such as `cite` on `blockquote`/`q`, or `datetime` on `ins`/`del`). IE doesn't render q correctly, but the content of the element is still available. As far as the attributes go, that's a UI problem with the browsers. :-) Come to think of it, as long as those attributes show up in the DOM correctly, I don't see how you could not support them. Perhaps we could say no *useful* browser support? [1] http://www.w3.org/TR/2001/REC-ruby-20010531/ Aankhen
Re: CGI Session management (was Re: the CGI.pm in Perl 6)
On 9/20/06, Fagyal Csongor [EMAIL PROTECTED] wrote: And maybe expand Web::HTML something like: Web::Markup::HTML Web::Markup::XHTML Web::Markup::WML etc... But that's might as well be too much. If those are modules to generate markup, I don't see why they should under the Web namespace. There needs to be a Web.pm toolkit (or something similar), but that's mostly an amalgamation of other modules. Aankhen
Re: Web development I: Web::Toolkit
On 9/20/06, A. Pagaltzis [EMAIL PROTECTED] wrote: I did qualify my statement. I'm sorry, I must have missed it. :-) Aankhen
Re: Web development I: Web::Toolkit
On 9/17/06, Amir E. Aharoni [EMAIL PROTECTED] wrote: WordPress is an example of a webserver software tool that does try to produce standard XHTML. It does it by default and very few bloggers who use it care about it or, for that matter, notice it. FuturisticPerl6WebPackage.pm should be like that too. I see no reason that autogenerated code won't conform to standard XHTML. Every deviation from standards and XML well-formedness should produce a warning. The point is not to have autogenerated code conform to the XHTML standard. The point is to not use XHTML simply because it's shiny. XHTML 1.0 and 1.1 offer no practical benefits over HTML, but tangible disadvantages. Using XHTML unnecessarily complicates processing and adds lots of gotchas. If someone still wishes to use it, Web.pm (or Web::Toolkit or Moo.pm or whatever it's called eventually) should be perfectly capable of producing well-formed XHTML... but please, not XHTML by default. Wishful thinking: FuturisticPerl6WebPackage.pm could have functionality that will output XHTML that adheres to both the w3c-standard and the defacto-standard (warning about tags that only works in certain browsers etc.) It might make it easier for developers to test their sites on several browsers and platforms. The majority of problems arising in authoring documents for the Web are due to poor implementations of CSS, not poor implementations of HTML. If the XHTML produced by the module adheres to the W3C standard, there won't be any elements that only work in certain browsers (with the exception of abbr... no others I can think of offhand). Aankhen -- I meant *our* species. You said *your* species. Evidently I am insane. May I go now?
Re: the CGI.pm in Perl 6
On 9/13/06, Leon Timmermans [EMAIL PROTECTED] wrote: On the other HTML outputting functions: They never really belonged in CGI in the first place I guess. There is no reason they cannot be generalized to XML outputting and be put in an appropriate library. There is, actually. HTML ne XML. HTML is an SGML application. XHTML is an XML application. The HTML generation functions definitely don't fit in CGI.pm, but neither should they be pushed out into an XML generation module, if only for the sake of conceptual clarity. Regarding the general CGI.pm in Perl 6 topic... I was working on porting HTTP::* from LWP to Perl 6 a long time ago, but I was unable to complete that. That was probably a year or so ago; if someone would like to take over and bring it up to date with the latest syntax and tricks, be my guest. There were a few discussions with Juerd and others in #perl6 about CGI.pm in Perl 6... if anyone's interested, I'll look for the logs. The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). Rather, there needs to be proper seperation of concerns. Maybe instead of just importing CGI, you'd now import HTTP::Request::CGI and HTML::Generator (I'm throwing names out at random, although I did write HTTP::Request::CGI as a subclass of HTTP::Request whose members are populated in a manner similar to CGI.pm's parsing of %ENV). Aankhen -- I meant *our* species. You said *your* species. Evidently I am insane. May I go now?
Re: [svn:perl6-synopsis] r7795 - doc/trunk/design/syn
On 23 Feb 2006 14:15:21 -, [EMAIL PROTECTED] Log: Typo, plus audrey forgot to increment version. There seems to be another typo on the same line: just as method like instead of just as methods like. Aankhen -- Why don't you go on a diet! Because I like to eat! Is that a crime?
Re: numification and stringification of objects
On 9/26/05, Yuval Kogman [EMAIL PROTECTED] wrote:
I think that this role should define the dump operator. Perhaps
prefix or postfix ?! can work... That seems fairly obvious. For
example
warn Done fetching $url, { $ua?! };
Let's call it the wtf operator.
No, please... how about just calling it the interrobang operator
http://en.wikipedia.org/wiki/Interrobang? :-D
Aankhen
Re: Do slurpy parameters auto-flatten arrays?
On 8/3/05, Piers Cawley [EMAIL PROTECTED] wrote: So how *do* I pass an unflattened array to a function with a slurpy parameter? Good question. I would have thought that one of the major gains from turning arrays and hashes into references in scalar context is the ability to specify an unflattened array or a hash in a sub call without any special syntax... Aankhen
Re: $arrayref.ref?
On 7/30/05, Larry Wall [EMAIL PROTECTED] wrote: On Sat, Jul 30, 2005 at 02:14:52PM +0200, Ingo Blechschmidt wrote: : say $arrayref.isa(Ref); # true or false? False, though tied($arrayref).isa(Ref) is probably true. In that case, how do you check if something is a ref? `if (tied($foo))`? Aankhen
Re: lazy list syntax?
On 7/29/05, Flavio S. Glock [EMAIL PROTECTED] wrote: Is for = only for filehandles? I tried: No, it's for anything that supports iteration... `=$foo` == `$foo.next()`, if I recall correctly. It's probably not yet implemented. Aankhen
Re: Messing with the type heirarchy
[sorry Luke, I hit Send too soon] On 7/27/05, Luke Palmer [EMAIL PROTECTED] wrote: There is probably a better word than contains. I was thinking set theory when I came up with that one. What about derives? Aankhen
Re: Database Transactions and STM [was: Re: STM semantics, the Transactional role]
On 7/18/05, Sam Vilain [EMAIL PROTECTED] wrote:
Is this needed, when you can just;
atomic {
unsafeIO { $dbh.begin_work };
unsafeIO { $dbh.do(...) };
unsafeIO { $dbh.commit };
} CATCH {
$dbh.rollback;
};
Shouldn't that `CATCH` block be within the `atomic` block? Or did I
miss something?
Aankhen
Re: WTF? - Re: method calls on $self
On 7/14/05, Larry Wall [EMAIL PROTECTED] wrote: Certainly. The problem is that there are too many viable alternatives, and half of everyone hates half of the alternatives. You will know I'm no longer a benevolent dictator when I start to enjoy watching people squirm every time I change my mind. Well, you've certainly got everyone flustered enough that they'll be overjoyed even if you pick the alternative they hated the most... :-) Aankhen
Re: WTF? - Re: method calls on $self
On 7/12/05, Juerd [EMAIL PROTECTED] wrote: [snip] Disallowing .method here means a huge step back in time. Back to $_.method or $object.method. [snip] I agree with what is being said here. `.method` is a great way to eliminate a lot of repetitive, tedious typing. Surely there is a viable alternative that doesn't involve outlawing it? Aankhen
Re: using rules
I'll take a shot at it since no one else seems to want to. :-) On 6/3/05, BÁRTHÁZI András [EMAIL PROTECTED] wrote: How can I catch the matched elem name, and block content? I'm guessing that hypotetical variables can be the solution, but it says, that those variables should have been defined, before I use them, and it's not that case. Named subrules have their values stored in the $/ match object under a key of the same name. So, in this case: $foo ~~ m/block/; $/block will contain the matched block, and $/block[1] will contain the block content (i.e. the content of the second capturing group). The working is the same in the case of s///, so you can probably safely use $/ within your trigger_block and trigger_elem. Hypothetical variables work like this: my $bar; # not quite sure you need to initialise it; just in case :-) $foo ~~ m/$bar := (bar|baz)/; Now $bar will contain either bar or baz, depending on which one was matched. Hope this is helpful. Corrections are welcome from anyone who spots any mistakes. Aankhen
Re: pugs 'make clean' fatal error on ms windows
On 5/31/05, Carl Franks [EMAIL PROTECTED] wrote: Running `make clean` on WindowsXP is dying with an expanded command line too long error. You need to get a later version of nmake. The latest is 7.10, I believe. Aank
