Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Orange Wizard]

I think I can see your problem...

Java

Yeah.

Spoiler (click to show/hide)

I actually have no idea, either, I'm afraid. I just wanted to take the opportunity to bash Java.

[Angle]

Why do people bash java? I mean, it's not perfect or anything, but it seems sufficient.

[Orange Wizard]

Well, YMMV. I don't like it because it feels clunky. You don't raise syntax errors, for example, you raise a java dot lang dot exception dot error dot syntax dot name, or whatever it is.

[Angle]

...No, you throw <ExceptionName>, after having imported java.lang.ExceptionName. The names are a bit long, but that's not really a problem.

[Telgin]

It's largely a historical matter.  When Java was new, it was very, very slow and had a comparatively gigantic memory footprint because of its VM interpreted execution model.  It was nice because it could run on a great number of platforms with minimal or no modification, but it didn't really run well on many or any of them.

That's not really true anymore.  These days with hotspot optimizations and other tricks it can be about as fast as anything else.  It's just mostly that the distaste for it became commonly known and trendy, so people still at least pay lip service to disliking it.

I have so little experience with it directly that I can't really comment on it as a language.

[Angle]

Alright, I found my control panel and got the error console to work, and solved that first problem. Now I have an entirely different stupid problem that makes no sense. I keep getting this error message: "Error: Error calling method on NPObject!" when I try to call the applets methods with javascript.

[Mephisto]

Dirty laundry removed.

[Maklak]

Perl is so infuriating. Simple examples of exporting functions and scalars work just fine, but when I tried something bigger, it suddenly wants me to put module_name:: in front of everything or doesn't work

http://pastebin.com/EhJ2Ktmt

[MagmaMcFry]

Perl is so infuriating. Simple examples of exporting functions and scalars work just fine, but when I tried something bigger, it suddenly wants me to put module_name:: in front of everything or doesn't work

http://pastebin.com/EhJ2Ktmt

Your problem is that Exporter only works if you load the module via "use Out" instead of "require Out", because only "use" calls the &Out::import method, which is the thing that Exporter generates for you. Use "use" instead and you won't need all the "Out::"s.

[Maklak]

Thank you. That was quick, helpful and actually works! Those simple examples that worked had "use" too, but I saw "require" and even "do" used to import a module somewhere and got confused.

[MagmaMcFry]

Oh, and by the way: I took your Out.pm and rewrote it from scratch, now it is awesome and easy to use and extend, and demonstrates good use of multiple files. Here's a link.

Here's how you would use it:

Code: [Select]

#!/usr/bin/perl

use Formatter;

# Let's write some BBCode. To do this, we simply create a new style and store it somewhere.
my $f = new Formatter::Style::BBCode;
# If we would want to write HTML instead, we could just write this instead:
# my $f = new Formatter::Style::HTML;
# And everything using $f would have still worked, except you would have created HTML code instead of BBCode. Neat, right?

# Really simple syntax. You don't have to mess with all those variables like $btb and $erow and $stbs.
$bbcode = $f->header();
$bbcode .= $f->big($f->green("This text is big and green!")) . $f->br() . $f->bold($f->red("This text is red and bold")) . $f->br();
$bbcode .= $f->table([["Top left","Top right"],["Bottom left", "Bottom right"]]);

print $bbcode, "\n\n";

#------------

# If you don't like all the '$f->'s and want even simpler syntax, you can also just let Formatter keep track of your current format like this:
use Formatter ":simple";
setStyle(new Formatter::Style::HTML::Linked);

print header();
print anchor("anchor", "Hey!"), br();
print table(
[
[ green("Foo"), red(italic("Foo")) ],
[ big("Foo"), bold("Bar") ],
]
);
# If your text has questionable symbols that could mess up your format, use the format's escape() method to make it safe:
print hr(), escape("<Blah>&&&</Foo>");
print hr(), alink("anchor", "There!"), br();

Neat, right? Hope it helps.

[Maklak]

$f->big($f->green("This text is big and green!")) . $f->br() . $f->bold($f->red("This text is red and bold")) . $f->br();

While this is more in-line with good programming practices, it is the solution I wanted to avoid in the first place. Compared to what I have at the moment, this solution has two flaws:
1) More verbose, but then it compensates for this by not having to worry about closing tags, which is a really good idea I haven't considered (and would hate it for table rows). Hm, actually $bbig . $bgreen . "This text is big and green!" . $ecolor . $ebig . $n . $bbold . $bred . "This text is red and bold" . $ecolor . $ebold . $n is longer and I guess I could live with the object syntax.
2) My way has some magic action at a distance (which is usually a bad thing, except I know exactly how it works, so that makes it OK, right?). With OO solution, I'd still need some factory and a my variable hidden in the output module to hold the type of output I need, so each function would begin with my $fmt = get_fmt;.
Basically I just call set_output when processing program options, then use those magic variables everywhere and not care what their actual content is. This way my concatenated strings look the same, which I like for it's simplicity. I just have to never ever write to those varables outside of that one file. With your way, I guess they would look the same too.
3) I have one smallish file that takes care of output formatting. It is stupid and rather easy to edit. Your solution is a maze of a lot of small files. I do not like that.

I didn't want to have too many variables, so I skipped html table title row, LaTeX output and some other stuff. With OO way, maybe I would be less inclined to cut corners.

For an even more proper solution, there would need to be a function that formats a table in a standard array of hashes (or complex stuff), but when I tried it, it quickly became so complex that I decided it's easier if each module builds it's own table. It eventually came down to having different classes for various types of table cells that know how to ToString() themselves.

Cocnlusion: Meh, I think the object way would work fine after all, but I'll use mine out of habbit.

Ugh, I've edited this several times and is still as messy as my code. I may be too tired.

[MagmaMcFry]

1) More verbose, but then it compensates for this by not having to worry about closing tags, which is a really good idea I haven't considered (and would hate it for table rows). Hm, actually $bbig . $bgreen . "This text is big and green!" . $ecolor . $ebig . $n . $bbold . $bred . "This text is red and bold" . $ecolor . $ebold . $n is longer and I guess I could live with the object syntax.
2) My way has some magic action at a distance (which is usually a bad thing, except I know exactly how it works, so that makes it OK, right?). With OO solution, I'd still need some factory and a my variable hidden in the output module to hold the type of output I need, so each function would begin with my $fmt = get_fmt;.
Basically I just call set_output when processing program options, then use those magic variables everywhere and not care what their actual content is. This way my concatenated strings look the same, which I like for it's simplicity. I just have to never ever write to those varables outside of that one file. With your way, I guess they would look the same too.

Have you scrolled down the code window in my previous post? Because I did actually implement a setStyle method that does exactly what your set_output does:

Code: [Select]

#!/usr/bin/perl
use Formatter ":simple";
setStyle(new Formatter::Style::HTML::Linked);

print header();
print anchor("anchor", "Hey!"), br();
print table(
[
[ green("Foo"), red(italic("Foo")) ],
[ big("Foo"), bold("Bar") ],
]
);
# If your text has questionable symbols that could mess up your format, use the format's escape() method to make it safe:
print hr(), escape("<Blah>&&&</Foo>");
print hr(), alink("anchor", "There!"), br();


3) I have one smallish file that takes care of output formatting. It is stupid and rather easy to edit. Your solution is a maze of a lot of small files. I do not like that.

If you don't like the amount of files, you can just append all the contents of the style files to the contents of the Formatter.pm file instead of having them as separate files. It will still work. Also I used lots of files primarily to show you how to split files the right way. But it's still considered better practice to have every public class in its own file.

[Maklak]

OK, look, I just skimmed it and came from a strong pre-conception that it would be easier to have a bunch of variables rather than methods. Your solution has some merits over mine that I'm slowly realizing and at the very least, it will be a good example when I need inheritance. Mine pollutes the global namespace with a lot of variables, but I know how it works, so it is easier (more natural) for me. Anyway, both will work for what I'm trying to do and output formatting is a problem I solved. Important problems are usually which RAW tokens are important, how to display them, how to rate things, etc. That said, I'm keeping your zip and will look at it some more.

[Gentlefish]

Why is lisp even a thing?