| Time |
S |
Nick |
Message |
| 01:16 |
|
|
cem_ joined ##javaee |
| 01:16 |
|
cem_ |
konichi wa |
| 01:18 |
|
pdurbin |
cem_: what's new? |
| 01:19 |
|
cem_ |
? pdurbin |
| 01:22 |
|
cem_ |
should i need to know xml to work on servlet ? |
| 01:24 |
|
pdurbin |
not really |
| 01:26 |
|
cem_ |
? |
| 01:30 |
|
cem_ |
my frnds say xml is very important and you say not ? confused |
| 01:31 |
|
pdurbin |
xml is important |
| 01:33 |
|
pdurbin |
cem_: you probably know a little about xml already |
| 02:12 |
|
* cem_ |
bit busy brb |
| 02:31 |
|
cem_ |
currently writing addition of 2 no program |
| 02:35 |
|
* cem_ |
fails consistenly to write addition of 2 no :( |
| 03:58 |
|
sfisque |
as far as xml is concerned, other than namespaces, schemas and dtds, xml is trivial, unless you're doing xslt stuff |
| 04:07 |
|
n448 |
sfisque: +++++++[>++++++++++<-]>++.+. |
| 04:07 |
|
sfisque |
brain fuck? |
| 04:07 |
|
n448 |
yea |
| 04:07 |
|
sfisque |
lolz |
| 04:07 |
|
n448 |
learning |
| 04:08 |
|
sfisque |
you would be better served learning basic over that language |
| 04:10 |
|
n448 |
k 'll learn xml |
| 05:10 |
|
|
sajjadg joined ##javaee |
| 05:39 |
|
|
dangertools joined ##javaee |
| 05:39 |
|
|
dangertools joined ##javaee |
| 05:48 |
|
n448 |
brb |
| 05:51 |
|
|
cem_ joined ##javaee |
| 08:09 |
|
|
mite_mitreski joined ##javaee |
| 08:41 |
|
|
weyer joined ##javaee |
| 09:51 |
|
|
sajjadg joined ##javaee |
| 09:54 |
|
|
neuro|sys joined ##javaee |
| 10:04 |
|
|
SoniEx joined ##javaee |
| 12:07 |
|
|
sajjadg_ joined ##javaee |
| 12:26 |
|
|
MegaMatt joined ##javaee |
| 12:34 |
|
|
weyer joined ##javaee |
| 12:35 |
|
|
SoniEx2 joined ##javaee |
| 12:39 |
|
|
drspockbr joined ##javaee |
| 13:37 |
|
|
sajjadg_ joined ##javaee |
| 13:37 |
|
|
slassh joined ##javaee |
| 13:52 |
|
|
waal70 joined ##javaee |
| 14:18 |
|
|
MiteMitreski joined ##javaee |
| 14:53 |
|
|
Naros joined ##javaee |
| 15:23 |
|
|
jieryn joined ##javaee |
| 15:23 |
|
|
jieryn joined ##javaee |
| 16:07 |
|
|
bluemd joined ##javaee |
| 16:10 |
|
SoniEx2 |
sometimes I wish Java had "import package java.lang;" and then you do "lang.Class" and stuff... |
| 16:10 |
|
SoniEx2 |
would be useful when types conflict |
| 16:14 |
|
sajjadg_ |
yeah. why not |
| 16:14 |
|
sajjadg_ |
suggest a JSR ;) |
| 17:29 |
|
|
weyer joined ##javaee |
| 17:37 |
|
|
bluemd left ##javaee |
| 18:05 |
|
Naros |
SoniEx2: I don't necessarily see the benefit of that. |
| 18:06 |
|
Naros |
Objects in java.lang are pretty straight forward generic things, specific to java. Either name your classes something more descriptive or perhaps you're trying to roll something that the language already provides you :P |
| 18:08 |
|
Naros |
if you have some class named "Class", perhaps just a variant name might make more sense such as "Course" if referring to something at a uni or school or if pertinent to scripting, ScriptClass or ScriptType, etc. |
| 18:09 |
|
sfisque |
i can see for cases where you're building a tool or deep framework, having "namespacing" would be handy, but i mostly agree with naros |
| 18:09 |
|
Naros |
Aye, that's definitely one thing i adore with C++ is the entire namespace concept. |
| 18:09 |
|
Naros |
reuse the same class names :) |
| 18:10 |
|
Naros |
but even in that environment, I've rarely seen use for it, its generally a sign that perhaps you might need to refactor that stuff into a common place if its the same similar stuffs |
| 18:11 |
|
Naros |
hehe, reminds me of my love-hate relationship with not having effective runtime type systems in C++ |
| 18:12 |
|
sfisque |
nature of the beast. native metal doesnt enable "introspection". you only get it because the jvm is instrumented to give it to us |
| 18:13 |
|
Naros |
precisely and many often argue if you need it in native languages, your implementation is flawed ;) |
| 18:14 |
|
sfisque |
well, there is a reason no one has produced a container like the EE container for native languages. no instrospection == too much "binder magic" |
| 18:15 |
|
Naros |
Yep. IIRC, the property management subsystem I wrote to allow designers to get metadata information on entity components in the entity framework we designed in-house, it was more code than the entire entity framework :P |
| 18:16 |
|
Naros |
Those darn deesigners and their point-n-click interfaces :/ |
| 18:16 |
|
Naros |
Just remember it was tons and tons of preprocessor definitions :( |
| 18:55 |
|
SoniEx2 |
back |
| 18:55 |
|
Naros |
wb! |
| 18:55 |
|
SoniEx2 |
lets say you have an API with a class named <insert name here> |
| 18:55 |
|
SoniEx2 |
then you have another API with a different class named <insert conflicting name here> |
| 18:56 |
|
SoniEx2 |
then it would be useful to have package imports |
| 18:57 |
|
Naros |
I presume you mean something like C++'s using namespace a; type concept |
| 18:57 |
|
SoniEx2 |
idk |
| 18:57 |
|
SoniEx2 |
does "namespace a;" require you to use a.<something> or something like that? |
| 18:57 |
|
Naros |
for example in boost there is a class called bitset<> but in the c++ std library there is bitset<> |
| 18:58 |
|
Naros |
so you can either 1) refer to them as boost::bitset<> and std::bitset<> or you can use the "using namespace" phrase to avoid denoting boost/std |
| 18:58 |
|
Naros |
but if you try to use both in the same context, you'll get clashes too and one must be prefixed. |
| 18:58 |
|
SoniEx2 |
oh no I want something like this |
| 18:58 |
|
SoniEx2 |
I mean |
| 18:58 |
|
SoniEx2 |
in C++ you don't have long package names |
| 18:58 |
|
SoniEx2 |
anyway |
| 18:58 |
|
SoniEx2 |
no |
| 18:59 |
|
Naros |
depends on the API :) |
| 18:59 |
|
SoniEx2 |
I want something like import package net.minecraft.block; |
| 18:59 |
|
Naros |
lots of private hidden stuffs is often hidden in deep namespace hierarchies :) |
| 18:59 |
|
SoniEx2 |
then you do block.Block or block.BlockFurnace etc |
| 18:59 |
|
Naros |
Yep, that's the using namespace concept |
| 19:00 |
|
SoniEx2 |
instead of net.minecraft.block.Block or net.minecraft.block.BlockFurnace or Block or BlockFurnace |
| 19:00 |
|
sfisque |
i guess what naros is indicating that there is not a "pervasive" need for this "feature". if you're constantly running up against this, you're probably doing something wrong, or reinventing an existing impl |
| 19:00 |
|
Naros |
so if i had a namespace hierarchy of boost::mpl::internal I could type |
| 19:00 |
|
Naros |
using boost; |
| 19:00 |
|
Naros |
then mpl::internal::whatever |
| 19:00 |
|
Naros |
er using namespace boost; |
| 19:01 |
|
Naros |
but I think in java the equivalent exists, hm |
| 19:01 |
|
Naros |
import net.minecraft.*; |
| 19:01 |
|
Naros |
block.somethingelse.method - would that work? |
| 19:01 |
|
sfisque |
right but you cannot import a package, you have to import a class or (glob of classes) |
| 19:01 |
|
sfisque |
he wants to import a package and then use it as a namespace qualifier |
| 19:02 |
|
SoniEx2 |
Naros: I don't think that work |
| 19:02 |
|
Naros |
Yah I see now, much like C++'s using namespace cherry picking scenario. But most IDEs in Java prefer import specific classes rather than a package. |
| 19:02 |
|
sfisque |
but either way, i don't see this as a "pervasive need". even the few times i've had "name collisions" it was only a scant couple of refs in the codebase adn using the FQN was trivial |
| 19:03 |
|
SoniEx2 |
but FQNs are ugly |
| 19:03 |
|
Naros |
Another JSR possibility would be to somehow introduce typedefs to Java |
| 19:03 |
|
sfisque |
java is ugly |
| 19:03 |
|
sfisque |
NO |
| 19:03 |
|
Naros |
:P |
| 19:03 |
|
sfisque |
typedefs are "t3h debil" |
| 19:04 |
|
Naros |
typedef com.minecraft.package mySpecialNamespace; |
| 19:04 |
|
Naros |
mySpecialNamespace.whatever.method() :P |
| 19:04 |
|
Naros |
Just call it something like a package alias or w/e |
| 19:04 |
|
sfisque |
though i had an epiphany the other day. with closures and "function" as a top level object, i'm betting we'll see "operator overloading (a la C++) in j9 or j10 |
| 19:04 |
|
Naros |
Wouldn't surprise me. |
| 19:05 |
|
SoniEx2 |
YAY! |
| 19:05 |
|
SoniEx2 |
that'll fix str == str2 |
| 19:05 |
|
semiosis |
in php we can alias an import a la "use Zend\ModuleManager\Feature\ConfigProviderInterface as ZendConfigProvider;" |
| 19:05 |
|
semiosis |
that struck me as odd since i'm so used to java |
| 19:05 |
|
Naros |
lol str == str2 ;/ |
| 19:06 |
|
Naros |
I dislike that crap in C++ world |
| 19:06 |
|
Naros |
Prefer my old school stricmp() functions :) |
| 19:06 |
|
Naros |
str.equals(str2) |
| 19:06 |
|
sfisque |
it seems like that would be the logical next step. the one blocker from op overloading is the fact that functions (and hence operators) are embedded in the jvm and functions are not top level objects (thus you cannot overload) |
| 19:07 |
|
sfisque |
remove the overloading blocker, and all you need to do is reimplement the operators as top level functions that can be then overloaded |
| 21:48 |
|
pdurbin |
in Python you can use "as" to name the object whatever you want while you're importing: from xml.etree import ElementTree as ET |
| 22:21 |
|
|
sajjadg joined ##javaee |
| 23:26 |
|
whartung |
just FYI, the GF connection pool seemed to recover cleanly for us after we failed over the DB beneath it. |
| 23:26 |
|
whartung |
the code had kittens and it sput out errors |
| 23:26 |
|
whartung |
but it eventually recovered |
| 23:40 |
|
|
acuzio joined ##javaee |
| 23:50 |
|
pdurbin |
+1 |
