ithout guessing) determine the documentation for a
certain element.
Also you could automatically test if every method/class/.. has been
documented etc.
Semantics are very useful in documentation, why throw them away?
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
ed beef hash".
To conclude, as hash definitely tastes better than a dictionary, we
should stick to that name. ;)
At least nobody can say that Perl is bad taste!
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
..
So there is no perfect candidate in the above list.
But in my opinion they are still more "english" than "hash".
Additionally I believe it would be easier to learn that it's (e.g.) a
dictionary that just is not ordered than learning a whole new word li
n explicit marker for "don't stop here, keep going".
That's the pro-semicolon reason that makes most sense in all comments
that I've read so far in this discussion.
But maybe that's just something where you have to get used to.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
chromatic schrieb:
> On Monday 14 May 2007 15:48:24 Thomas Wittek wrote:
>
>> But it should be no problem to put out a warning/error at runtime (or
>> maybe even at compile time) when a variable name clashes with a method
>> name.
>
> Do you always know all of t
Juerd Waalboer schrieb:
> Thomas Wittek skribis 2007-05-15 0:48 (+0200):
>>> The Perl Way:
>>> $object.foo() calls the method called "foo".
>>> $object.$foo() calls the method that is in the variable $foo.
>> My way:
>> someref = &somemeth
; I think the lack of value here outweights the "savings" of one character
> per line.
But even if the advantage of line termination is low (some characters
saved, some people might say it looks cleaner), I cannot see any
advantage of semicolon termination.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
d of the common cases.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Juerd Waalboer schrieb:
> Thomas Wittek skribis 2007-05-14 0:42 (+0200):
>> excessive use of special characters (/\W/).
>
> This seems to be "I don't like regexes". Ignoring for now that Perl 6
> regexes will be more verbose and thus easier to read for someone
Juerd Waalboer wrote:
> Thomas Wittek skribis 2007-05-14 22:20 (+0200):
>> But I think that the name of an identifier (noun/verb, single/plural,
>> the meaning of the word) already gives enough context to understand what
>> type it is.
>
> [examples]
You are right,
ason for them.
> I agree. You need less ignorant colleagues. I'm not sure Perl 6 can fix
> that.
I don't think that it's a point of ignorance.
Especially as they (and enough other people on the web) only seem to be
ignorant regarding Perl. Strange, huh?
> By the way, I&
tional hint for the type.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Andy Armstrong schrieb:
On 14 May 2007, at 12:31, Thomas Wittek wrote:
How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc.
know?
They didn't.
If there is a new release, you always have to check if your code still
runs.
I think that may be the point I'm maki
f
being open for ideas and discussing them from a neutral point of view?
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Andy Armstrong schrieb:
On 14 May 2007, at 11:51, Thomas Wittek wrote:
I also can't remember that I ever named a variable like a "reserved
word" or operator. And even if I could, I'd consider it to be bad style.
How did you know which reserved words and operators were goi
warning for that.
So maybe it'd be a good idea to completely drop it.
People not only want code that _is_ sexy, but they also want it to
_look_ sexy.
At least almost everyone to whom I said, that I do most work in Perl,
responded with some sentence containing the word "ugly" or &
eryone agreed that
sigils (or forced semicolons, or tons of operators, ...) are more bad
than good (and this seems like persuading the pope to allow homosexual
muslims to marry with priests) the design process is probably too far to
introduce such dramatic changes.
Sadly.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
e_of_the_co_6.html
[2] http://www.google.com/trends?q=perl%2C+python+-snake%2C+ruby
People not only want code that _is_ sexy, but they also want it to
_look_ sexy.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
/Any/gather directly, I think.
> On the other hand, there is no important reason for it because C<
>
> for @rray -> $el {}
> if ! @rray {}
>
> should work. It's short and easy to understand.
Agree, this looks good indeed.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
Darren Duncan schrieb:
> At 11:17 PM +0100 3/3/07, Thomas Wittek wrote:
>> Larry Wall:
>>> : if ($item = 'foobar') {
>>
>> == of course ;)
>>> If you actually wrote that, then you'll always find that the first
>> > item ha
ng where I'd say "wow, thats an easy solution to my problem!".
It's a bit complicated, because you have to understand and combine
several concepts. That's elegant. But not easy, I think.
I think it's not simple enough for this simple kind of problem.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
"
} end {
say "The end has been reached. 42 not found."
} empty {
say "No items."
}
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
stuff) {
..
}
} else {
..
}
many times. An else block would save keystrokes and would make the code
more readable. Python also has it.
What do you think?
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
the usability of a tool greatly influences it's acceptance and usage,
this is a point, where we really should think about.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
e to create an
operator with the same name?
zip(@a; @b) -> function
@a zip @b -> operator
Or would that lead to grammar ambiguities, that are impossible to resolve?
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
reate a more semantic
markup which can be styled using CSS.
Of course there is more than just design. The cite attribute of the
blockquote tag isn't supported by any browser AFAIK.
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
lines
CGI.pm/Web.pm/foo.pm that covers the most common web-request tasks.
Regards
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
ith the getting (and setting) of the incoming param values.
A separate module, say HTML::Formgenerator, could easily use CGI.pm (or
Web.pm,...) to get and set parameters:
$value = $query->param('foo');
$query->param('foo','an','array','of'
don't think that this qualifies as a compelling
> reason to change it - especially since it's so easy to add aliases via
> modules
As Smylers said above: Please, no more aliases. They only create confusion.
Regards
--
Thomas Wittek
http://gedankenkonstrukt.de/
Jabber: [EMAIL PROTECTED]
e meaning, what's not always the case
when you're reading code (of a language) that you haven't read for a
while. Also you can usually type them more quickly as the word-charactes
have a more prominent position than the special characters on most keybords.
Best Regards
--
Thomas
Steffen Schwigon schrieb:
> Thomas Wittek <[EMAIL PROTECTED]> writes:
>> An other acceptable solution would be to create a backwards
>> compatible P6 CGI.pm and create a new Web.pm with an all new
>> interface, like Mark suggested.
> I would strongly expect the CGI m
Trey Harris schrieb:
> I agree with the sentiment, but as a practical matter, not having HTML
> methods in CGI.pm could drastically limit Perl 6 adoption.
Oh well. I thought it was common sense that it's a bad idea to mix code
and markup. Who really wants to do itself this pain should use a
separa
Markus Laire schrieb:
>> Operators/reserved words should be lowercase. Period. ;)
>> I think that this would heavily break consistency, annoying new users.
>
> There are already many uppercase reserved words in perl6:
>
> Pseudo-packages from S02
> MY, OUR, GLOBAL, OUTER, CALLER, CONTEXT, SUPER,
> Bearing that in mind, would the eye-socket-burning
>
> return $foo
> IF $something;
>
> really be so bad?
Operators/reserved words should be lowercase. Period. ;)
I think that this would heavily break consistency, annoying new users.
-Thomas
Steffen Schwigon:
> Thomas Wittek <[EMAIL PROTECTED]>:
>> Maybe I just phenomenally misunderstood multi subs, but unless I
>> did, I can't see why we want to have subs when we can have multi
>> subs that can do the same and even more.
>
> I understand
Steffen Schwigon schrieb:
> At least the many keywords seem to be necessary to map the complexity
> of different paradigms possible in Perl6. Multimethods are not just
> overloading as in C++. Second, the different keywords declare
> different behaviour you can choose. Just read S06, it's explained
Conrad Schneiker schrieb:
> 3) (Quoting from above link): "I propose that the wiki be called P6 to
> signify its use of Perl6." I presently prefer something like the
> "Perl++ Wikicosm".
Another idea: Wiki is hawaiian for "quick, fast". Why not take another
hawaiian word? Some examples (you will f
max demmelbauer schrieb:
> * how can i serialize objects (like the use Storable qw(freeze thaw) in
> perl5.8)
Try $object.perl(.say) as stated in
http://svn.openfoundry.org/pugs/docs/articles/tpr.pod (or
http://gedankenkonstrukt.de/perl6doc/articles/tpr.html ;) )
-Thomas
Damn, forgot the link.
Thomas Wittek schrieb:
> That's mainly what I did as stated in my first post[1]. [...]
[1]:
news://nntp.perl.org:119/[EMAIL PROTECTED]
Juerd schrieb:
> * Markdown does not have tables.
> * Textile does not have paragraphs in table cells.
> * Kwiki does not have paragraphs in table cells.
>
> Unless someone comes up with another way to do side-by-side layouts
> (extremely useful for showcasing differences between Perl 5 and Perl 6
Udo Güngerich schrieb:
> Thomas Wittek wrote:
>> Unfortunately you probably have to throw away/heavily modify earlier
>> increments, if you add features like a flexible syntax, which will need
>> a different internal infrastructure.
>
> Well, if object-oriented desi
Udo Güngerich schrieb:
> Why not doing a wiki system that does NOT have a fix syntax but rather
> allows defining its syntax rules in e.g. YAML and thus being entirely
> flexible?
> [..]
> It should have a proper user/groups system as well...
> [..]
> Why not give the wiki a web service API [..]
G
A. Pagaltzis schrieb:
> * Thomas Wittek <[EMAIL PROTECTED]> [2006-06-03 22:30]:
>> Interestingly it is very similar to Markdown although I never
>> heard about it before :)
>
> Hmm, it doesn’t look similar at all to me?
Headers (Markdown):
# This is an H1
## This is
A. Pagaltzis schrieb:
> * Amir E. Aharoni <[EMAIL PROTECTED]> [2006-05-28 23:00]:
>> The popularity of Wikipedia made Media-Wiki syntax the de-facto
>> standard. It's not perfect, but please don't reinvent the wheel
>> (even though it's a PHP wheel).
> [..]
> Noone other than Mediawiki uses the Med
Thomas Wittek wrote:
> Where should I start, when I want to get myself a picture of the current
> Perl 6 language features and syntax?
To conclude this, I'll give a list of online docs I find interesting
about learning Perl6:
1) Synopses:
http://dev.perl.org/perl6/doc/synopsis.ht
Where should I start, when I want to get myself a picture of the current
Perl 6 language features and syntax? Where is the best place to take a
look at, when I want to start experimenting with Perl 6 and pugs?
Would you recommend reading the synopses[1]?
Or should I take a look at pugs-doc?
Or is
herbert breunung schrieb:
> its understood that i will try, once finished to translate it for the
> pugs trunk.
Might have been better vice versa. First write it in english and then
translate it to german. This way you would've got more responses on that...
-Thomas
47 matches
Mail list logo
