[Ffmpeg-devel] Re: FFMPEG code a mess

[Gábor Farkas]

Dave Dodge wrote:
> On Sun, Sep 18, 2005 at 11:11:38PM +0100, M?ns Rullg?rd wrote:
> 
>>- Everything has to be an object.
> 
> 
> Ironically I've seen OO purists complain that Java _doesn't_ require
> everything to be an object (referring to the already-mentioned numeric
> types).

yes ;)

btw. having them as objects would make certain things simpler.

by 'having them as objects' i mean that you could treat them as objects 
(inherit from them and things like that).

but this did not even became an issue for me.

personally, i prefer python to java btw...
> 
> 
>>- No unsigned types.
> 
> 
> How they managed to design the language without at least a proper
> unsigned "byte" or "octet" type boggles the mind.  Gosling's been
> quoted a few times saying things like unsigned math is "too
> complicated".

;)

i've also heard stuff like that...

but i think that reducing the number of integer data types is a good 
thing for a language such as Java. imho you shouldn't have to care about 
  things like what if you subtract a long from an unsigned long, and 
things like that, but maybe it's only me.

interfacing with binary code can be a pain, that's true btw ;)

but mostly when someone uses an unsigned data type i see code that 
relies in some way on it's boundaries (for example that it gets higher 
than it's maximum, it becomes zero), which is not a good thing imho.

and to add more here (maybe it sounds as blasphemy ;), i usually don't 
care whether it's int or long.

i use mostly int, when i'm sure the represented number will fit into 32 
(or 31) bytes, but that's all.

mostly when i use an 'int', what i want to represent is that i use an 
integer number. for example, python is trying to get rid of the 
'int'/'long' data types and only have one integer data type. i like the 
idea.

of course, when i'm allocating big arrays of integers, i care if it's a 
byte or a long. but situations like that do not arise that often.

hmm, i'm sure it arises often in the video-compression/decompression are 
a. that's why i said java is not the best lang for this ;>


> 
> In some ways, Java is nice because it has standardized cross-platform
> support for threading and networking.  It's also a relatively simple
> language, especially compared to something like C++.  I've used it to
> experiment with ideas and prototype things that had to run on
> e.g. Solaris and Windows, with good results.  But the lack of unsigned
> types makes actually implementing network protocols and interfacing
> with native data formats very painful.

i agree
> 
> Somre other issues with Java:
> 
>   - It's a moving target.  Developers jump to use features from the
>     very latest release, while many users only have older JVMs readily
>     installed.  When I did my own Java coding I usually stuck to Java
>     1.1 even though at least 1.3 was available.  Granted, my code had
>     no GUI so I didn't have any AWT/Swing concerns.

for me it seems that java on the client side is pretty much dead. one of 
the reasons is your next issue ;)
and on the server side, java version number usually does not matter, 
because you usually can install the version you need.
you're correct that it's nicer if you don't use the newest features, but 
when they make your work sooo simpler (String.split for example in java 
1.4 ;), it's hard to resists ;)

> 
>   - The Sun license is problematic for Linux distributions.  See above
>     point about users not having the latest version readily installed.

100% agree
> 
>   - I know someone who just recently had trouble with some work
>     requiring lots of address space on an x86_64 machine, because a
>     64-bit-clean JVM wasn't available on that architecture.  His final
>     architecture will be ia64 but he was hoping to prototype on x86_64
>     in the meantime.

this is partly the result of sun's idiotic licensing schema. if they'd 
release it as "real" open-source, this wouldn't be such a problem.

gabor