- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
java enums more compact, flexible and obvious than scala's equivalent?
Sorry for what might seem like a trolling subject line, but this is a bit of a shocker since I usually find elegance in Scala rather than Java.
I am dealing with some legacy record layouts and in Java I have something like this
public enum FlatFileHeaderMapping {
FIELD1(1), FIELD2(5), // And loads more, elided for the sake of (your) sanity FIELDN(4)
public final int fieldSize;
private FlatFileHeaderMapping(final int fieldSize) { this.fieldSize = fieldSize; }}
which I can then use to place each line into a map:
public ProcessLegacyRecord(final String inputString) {
// Specify LinkedHashMap to retain insertion order LinkedHashMap<FlatFileHeaderMapping, String> headerValuesMap;
headerValuesMap = new LinkedHashMap<FlatFileHeaderMapping, String>(); int currPos = 0; for (FlatFileHeaderMapping m : FlatFileHeaderMapping.values()) { int endPos = currPos + m.fieldSize; String HeaderValue = inputString.substring(currPos, endPos); headerValuesMap.put(m, HeaderValue); currPos = endPos; } }
and later access the keys in the map via this enum:
String field1 = headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
Enumeration does not have these qualities as far as I can see, and case classes are not ordered like the enum values - so cannot be used to match a record layout as shown above. At least not without the support of an ordered collection.
I could be missing something obvious, hence the question!
Or please feel free to tear up the enum aspect and suggest a more functional, Scala-esque way to deal with fixed length inputs in a type safe / symbolic / elegant way!
Thanks
Ray
PS I also posted a shorter form of this question to SO http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
I am dealing with some legacy record layouts and in Java I have something like this
public enum FlatFileHeaderMapping {
FIELD1(1), FIELD2(5), // And loads more, elided for the sake of (your) sanity FIELDN(4)
public final int fieldSize;
private FlatFileHeaderMapping(final int fieldSize) { this.fieldSize = fieldSize; }}
which I can then use to place each line into a map:
public ProcessLegacyRecord(final String inputString) {
// Specify LinkedHashMap to retain insertion order LinkedHashMap<FlatFileHeaderMapping, String> headerValuesMap;
headerValuesMap = new LinkedHashMap<FlatFileHeaderMapping, String>(); int currPos = 0; for (FlatFileHeaderMapping m : FlatFileHeaderMapping.values()) { int endPos = currPos + m.fieldSize; String HeaderValue = inputString.substring(currPos, endPos); headerValuesMap.put(m, HeaderValue); currPos = endPos; } }
and later access the keys in the map via this enum:
String field1 = headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
Enumeration does not have these qualities as far as I can see, and case classes are not ordered like the enum values - so cannot be used to match a record layout as shown above. At least not without the support of an ordered collection.
I could be missing something obvious, hence the question!
Or please feel free to tear up the enum aspect and suggest a more functional, Scala-esque way to deal with fixed length inputs in a type safe / symbolic / elegant way!
Thanks
Ray
PS I also posted a shorter form of this question to SO http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
Re: java enums more compact, flexible and obvious than scala's
It's saying a lot. Most people are terrible listeners. Somebody talks at them and they only half listen because they already think they know what the person wants to say. They don't like what the person has to say and so they twist it into something else. Sometimes people are just looking for an argument, and they take everything that is said to them as an affront.
Take for example. You seem to think that I want the Scala language to have an enum language feature, and that I am complaining because it does not have one. I am quite happy using hierarchies of case objects in place of enums, and I think that adding enums to the Scala language is not necessary and would make the language less elegant. But, it would have been much better for me if, the first time I tried to "make an enumeration type" in Scala, I had found a clear and simple example of how to do enums with Scala case objects, and had not found scala.Enumeration instead. I did find some hints and suggestions here and there that eventually led me to figure out a relatively decent pattern for replacing enums on my own, but I found out by trial and error, and I'm not convinced that the solution I have settled on couldn't be improved upon.
Of course listening does not mean just saying "yes" to whatever your users ask for. That's not really listening at all actually, is it? A very simple turing machine could do the same. Listening means trying to understand what the person actually wants or needs. When you have a pattern of conversations with your users that goes, while (true) { "I want this", "No you don't, that's stupid" }, you need to break out of the loop and see what you are missing. (I know that's not a fair characterization of this conversation, but it certainly can feel that way to someone posting to a list in hopes of getting some help with a programming problem they are having.)
Good listening includes making the translation from what the user thinks they want, or says they want, to what they actually need. As the software developer we are in a position to say, "you are asking for this particular feature, but the problem you are actually trying to solve is such-and-such. Let me suggest some other ways of achieving your goal than the specific feature you have requested."
--
There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.
Re: java enums more compact, flexible and obvious than scala's
As Josh said a while ago, it's kitten time now.
I think we made progress.
Thanks for your help and support.
On 28 June 2011 14:42, john sullivan wrote:
>> > Number one rule of software development is Listen To Your Users.
>>
>> That's not really saying much.
>
> It's saying a lot. Most people are terrible listeners. Somebody talks at
> them and they only half listen because they already think they know what the
> person wants to say. They don't like what the person has to say and so they
> twist it into something else. Sometimes people are just looking for an
> argument, and they take everything that is said to them as an affront.
> Take for example. You seem to think that I want the Scala language to have
> an enum language feature, and that I am complaining because it does not have
> one. I am quite happy using hierarchies of case objects in place of enums,
> and I think that adding enums to the Scala language is not necessary and
> would make the language less elegant. But, it would have been much better
> for me if, the first time I tried to "make an enumeration type" in Scala, I
> had found a clear and simple example of how to do enums with Scala case
> objects, and had not found scala.Enumeration instead. I did find some hints
> and suggestions here and there that eventually led me to figure out a
> relatively decent pattern for replacing enums on my own, but I found out by
> trial and error, and I'm not convinced that the solution I have settled on
> couldn't be improved upon.
> Of course listening does not mean just saying "yes" to whatever your users
> ask for. That's not really listening at all actually, is it? A very simple
> turing machine could do the same. Listening means trying to understand what
> the person actually wants or needs. When you have a pattern of conversations
> with your users that goes, while (true) { "I want this", "No you don't,
> that's stupid" }, you need to break out of the loop and see what you are
> missing. (I know that's not a fair characterization of this conversation,
> but it certainly can feel that way to someone posting to a list in hopes of
> getting some help with a programming problem they are having.)
> Good listening includes making the translation from what the user thinks
> they want, or says they want, to what they actually need. As the software
> developer we are in a position to say, "you are asking for this particular
> feature, but the problem you are actually trying to solve is such-and-such.
> Let me suggest some other ways of achieving your goal than the specific
> feature you have requested."
>
>>
>> All relationships between providers of
>> something and users or consumers of that thing require a dialog. But
>> listening to your users doesn't mean saying "yes" to everything they
>> ask for. That is a nearly guaranteed recipe for chaos and failure.
>>
>> Martin has made it clear that cost in terms of language complexity for
>> something as limited in its payback as Java-style enums is not
>> acceptable. So those who cannot do without them can wail and gnash
>> their teeth all they want, but they're not going to get what they want
>> this time. So why persist?
>>
>>
>> Randall Schulz
>
>
>
> --
> There are more things in heaven and earth, Horatio,
> Than are dreamt of in your philosophy.
>
Re: java enums more compact, flexible and obvious than scala's
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is very true. Learning category theory and understanding algebra
are definitely good things, but those sorts of reponses are very
off-putting to newcomers, and aren't very helpful in the short- or
medium-term.
On 06/27/2011 08:25 AM, Matthew Pocock wrote:
> I don't personally find responses along the lines of, "learn category
> theory" and, "you should understand algebra" either leads anyone towards
> enlightenment or welcomes them into the scala community.
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk4IoCsACgkQ0GFaTS4nYxtzIACdEYgRj2mh+3t9p1ouDp4sZqGQ
U/sAoIDoTlPIIo8SYFz6CiQ2lT7J6MeN
=QOWl
-----END PGP SIGNATURE-----
Re: java enums more compact, flexible and obvious than scala's
On Monday 27 June 2011, Clint Gilbert wrote:
> This is very true. Learning category theory and understanding
> algebra are definitely good things, but those sorts of reponses are
> very off-putting to newcomers, and aren't very helpful in the short-
> or medium-term.
>
> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
> > I don't personally find responses along the lines of, "learn
> > category theory" and, "you should understand algebra" either leads
> > anyone towards enlightenment or welcomes them into the scala
> > community.
These things are _fundamental_ to this profession. If you won't learn
them, you don't deserve the attribute "professional."
And I feel that Scala is a tool for professionals, not dilettants. You
don't have to know all these things to start to use it, but you should
be willing to learn in order to understand why things are as they are
and to be able to create sound artifacts.
The reason computer systems are so hideously unreliable and error-prone
today is exactly 'cause so many of its paid, putatively professional
practitioners are ignorant of these principles. The sooner we put our
understanding on a sound formal groundwork, the sooner we can get
reliable information systems to the world.
And yeah, I myself have a long way to go. But I appreciate being pointed
in the right direction by those who are further down the road to a good
understanding. Ignorance is not shameful, but the refusal to fill it in
with understanding when you come to realize that ignorance _is_.
Randall Schulz
Re: java enums more compact, flexible and obvious than scala's
On Mon, Jun 27, 2011 at 8:40 AM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
I heard myself from Guido van Rossum that he does not know category theory and is not planning to learn it.
Python may be <inject your expletive here>-prone, but you can't say Guido is not a professional, eh?
-Vlad
Re: java enums more compact, flexible and obvious than scala's
There is a very funny/sad book called "Night Watch" by Terry Pratchett that talks about how, if political revolution isn't accepted by the people, then the obvious next step is that you need to change the people. I sense some amount of that feeling around Scala--"if people don't see the brilliance of Scala, then the people need to be changed." Well, people do see a lot of the brilliance of Scala, and that's great; but enums are something the keep coming up, which should make us think not, "how do we change people", but, "how do we do enums properly in Scala in a way that will be accepted by the audience we are aiming at.
Oh and I'm serious about the tutorials, so please feel free to provide links.
Ken
Re: java enums more compact, flexible and obvious than scala's
On Tue, Jun 28, 2011 at 12:54 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:
Indeed. Yet, they are nonetheless cleverly re-inventing concepts from category theory (or are using concepts that category theory explains elegantly), or, in failing to re-invent the concepts, are sometimes writing less-fantastic, less-tight, less-reliable code compared to what could be done in that case.
But I don't think this means that they're not professional _programmers_. It means they're not _category theory professionals_. It's the same difference between being a scientist and a philosopher of science, or between being a tennis player and a sports biophysicist. You can do the right thing--very reliably, even--without understanding, explicitly and in detail, the theory that explains why and how the thing works. Sometimes that detailed understanding is even more of a distraction than a help (e.g. tennis--I doubt Rafael Nadal is, when swinging for a serve, thinking about tensing his muscles such that a large portion of his inertial mass is apparent to the ball upon contact with the racket).
You do have additional options for problem-solving when you understand the generalizations and theory of what you're doing, so it's useful even if not essential.
--Rex
Re: java enums more compact, flexible and obvious than scala's
Thanks,Ken
Re: java enums more compact, flexible and obvious than scala's
I recently got pointed to this book: http://www.amazon.com/gp/product/0199237182
I just received it today. A quick perusal seems to support the claim that it's relatively approachable for the non-professional mathematician. The person who recommended it was very enthusiastic about it. Hope that helps.
--
Jim Powers
Re: java enums more compact, flexible and obvious than scala's
http://hseeberger.wordpress.com/2010/11/25/introduction-to-category-theo...
http://www.cs.toronto.edu/~sme/presentations/cat101.pdf
On Tue, Jun 28, 2011 at 16:20, Ken McDonald wrote:
> As mentioned before, I'm certainly willing to have a go at learning category
> theory if someone can point me at a link (Category Theory For The Compleat
> Idiot would be good.) This page is getting so crowded, might be best to
> email me as well as posting: ykkenmcd _ at _ gmail.com.
> Thanks,
> Ken
Re: java enums more compact, flexible and obvious than scala's e
Today I studied Category Theory and I think I just might come up with
a Scala Enumeration type that is almost identical to something very
similar to Java's, and with Category Theory of course.
On Jun 28, 9:20 pm, Ken McDonald wrote:
> As mentioned before, I'm certainly willing to have a go at learning category
> theory if someone can point me at a link (Category Theory For The Compleat
> Idiot would be good.) This page is getting so crowded, might be best to
> email me as well as posting: ykkenmcd _ at _ gmail.com.
>
> Thanks,
> Ken
Re: Re: java enums more compact, flexible and obvious than scal
My current day-job involves writing Python code. As some of you may know, there are no built-in constructs for enums in Python. Hell, there aren't even any built-in constructs for performing switch statements.
While the lack of the former hasn't affected me much, the lack of the latter is rather irrtating. Nevertheless,if one needs something enum-like or something switch-like there are options and the lack of built-ins hasn't killed anyone.
What I'm trying to say is that coming from Java it might seem that X (X being enums in this case) is a vital language construct given that it exists in Java. Nevertheless, this is not truly the case.
Scala is not Java. Some differences might irritate or frustrate, some might make you dance with happiness.Nevertheless, it's unlike any of them are going to cost you your job or sanity...
On a final note, I think it's interesting to see what solutions people have put together on their own forEnum-like support. While it's nice for a language to have feature X built-in, it's also cool to see what people do when feature X is not built-in, especially if the language is one like Scala where there are so manypossibilities...
Re: Re: java enums more compact, flexible and obvious than scal
Professional Computer Scientist or Professional Developer?
Before you leap, there is a difference and it's not as simple as: Computer Scientist > CS Grad Developer > Non-CS Grad Developer
Re: Re: java enums more compact, flexible and obvious than scal
Thanks,
-Vlad
On Tue, Jun 28, 2011 at 9:33 PM, Adam Jorgensen <adam.jorgensen.za@gmail.com> wrote:
Re: java enums more compact, flexible and obvious than scala's
On Tue, Jun 28, 2011 at 12:54 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:
Re: java enums more compact, flexible and obvious than scala's
2. Where are the kittens?
3. Can I have a poney?
On Tue, Jun 28, 2011 at 14:46, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
--
Daniel C. Sobral
I travel to the future all the time.
Re: java enums more compact, flexible and obvious than scala's
be careful what you wish for ;)
On Jun 28, 2011 2:41 PM, "Daniel Sobral" <dcsobral [at] gmail [dot] com> wrote:> 1. Where are the unicorns?
> 2. Where are the kittens?
> 3. Can I have a poney?
>
> On Tue, Jun 28, 2011 at 14:46, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com>wrote:
>
>> Even better...
>>
>> [image: scala-lang-place-for-friends.png]
>>
>>
>> On Tue, Jun 28, 2011 at 12:54 PM, Ken McDonald <ykkenmcd [at] gmail [dot] com> wrote:
>>
>>> > On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>>>> > > I don't personally find responses along the lines of, "learn
>>>> > > category theory" and, "you should understand algebra" either leads
>>>> > > anyone towards enlightenment or welcomes them into the scala
>>>> > > community.
>>>>
>>>> These things are _fundamental_ to this profession. If you won't learn
>>>> them, you don't deserve the attribute "professional."
>>>>
>>>>
>>>> Um, no, they are not. There are a great many true professionals out there
>>> writing fantastic, tight, reliable code, who don't have a clue what category
>>> theory or algebraic data types are. I worked for a company (Be Inc.) that
>>> was filled with them, and I read their code. Unit testing is _fundamental_
>>> to this profession. Consistent APIs are _fundamental_ to this profession.
>>> Category theory--_not_ fundamental. Nice to have, and if someone points me
>>> to good tutorials on cat theory and alg data types I'll go through them--but
>>> hey, I'm unemployed.
>>>
>>> There is a very funny/sad book called "Night Watch" by Terry Pratchett
>>> that talks about how, if political revolution isn't accepted by the people,
>>> then the obvious next step is that you need to change the people. I sense
>>> some amount of that feeling around Scala--"if people don't see the
>>> brilliance of Scala, then the people need to be changed." Well, people do
>>> see a lot of the brilliance of Scala, and that's great; but enums are
>>> something the keep coming up, which should make us think not, "how do we
>>> change people", but, "how do we do enums properly in Scala in a way that
>>> will be accepted by the audience we are aiming at.
>>>
>>> Oh and I'm serious about the tutorials, so please feel free to provide
>>> links.
>>>
>>> Ken
>>>
>>
>>
>
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.
Re: java enums more compact, flexible and obvious than scala's
On 28 June 2011 18:46, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:
Re: java enums more compact, flexible and obvious than scala's
I really wish it were commonly held wisdom that unit testing is
fundamental, but my experience indicates that this is not the case!
On Tue, Jun 28, 2011 at 5:54 PM, Ken McDonald wrote:
>> > On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>> > > I don't personally find responses along the lines of, "learn
>> > > category theory" and, "you should understand algebra" either leads
>> > > anyone towards enlightenment or welcomes them into the scala
>> > > community.
>>
>> These things are _fundamental_ to this profession. If you won't learn
>> them, you don't deserve the attribute "professional."
>
> Um, no, they are not. There are a great many true professionals out there
> writing fantastic, tight, reliable code, who don't have a clue what category
> theory or algebraic data types are. I worked for a company (Be Inc.) that
> was filled with them, and I read their code. Unit testing is _fundamental_
> to this profession. Consistent APIs are _fundamental_ to this profession.
> Category theory--_not_ fundamental. Nice to have, and if someone points me
> to good tutorials on cat theory and alg data types I'll go through them--but
> hey, I'm unemployed.
> There is a very funny/sad book called "Night Watch" by Terry Pratchett that
> talks about how, if political revolution isn't accepted by the people, then
> the obvious next step is that you need to change the people. I sense some
> amount of that feeling around Scala--"if people don't see the brilliance of
> Scala, then the people need to be changed." Well, people do see a lot of the
> brilliance of Scala, and that's great; but enums are something the keep
> coming up, which should make us think not, "how do we change people", but,
> "how do we do enums properly in Scala in a way that will be accepted by the
> audience we are aiming at.
> Oh and I'm serious about the tutorials, so please feel free to provide
> links.
> Ken
Re: java enums more compact, flexible and obvious than scala's
On Mon, Jun 27, 2011 at 11:40 AM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
And if, due to whatever circumstances that aren't really your business, someone cannot, does not, or does not want to, learn category theory, or relate to Scala as a mathematical body, then *you* *feel* that Scala is not for him??
So Scala enums present a barrier to creating a deterministic world! Poor athiests...
Not as shameful as disrespectful behavior.
Re: java enums more compact, flexible and obvious than scala's
Randall,
We're all willing to learn... it's why we are on these groups and
learning new languages.
I can (almost literally) feel your passion - and that's good. Please
however bear in mind that tone is important when one is trying to
encourage others.
As to enums, you never know, other FP languages might also have
support for Enums. I had a quick check and they are part of Haskell,
which I understand is a first class FP language. "Class Enum defines
operations on sequentially ordered types."
(http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelu...).
I don't want to get into a war of Scala vs Haskell. I'm just saying
that this is not a purely Java language aspect.
Best regards
Ray
On 27 June 2011 15:40, Randall R Schulz wrote:
> On Monday 27 June 2011, Clint Gilbert wrote:
>> This is very true. Learning category theory and understanding
>> algebra are definitely good things, but those sorts of reponses are
>> very off-putting to newcomers, and aren't very helpful in the short-
>> or medium-term.
>>
>> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>> > I don't personally find responses along the lines of, "learn
>> > category theory" and, "you should understand algebra" either leads
>> > anyone towards enlightenment or welcomes them into the scala
>> > community.
>
> These things are _fundamental_ to this profession. If you won't learn
> them, you don't deserve the attribute "professional."
>
> And I feel that Scala is a tool for professionals, not dilettants. You
> don't have to know all these things to start to use it, but you should
> be willing to learn in order to understand why things are as they are
> and to be able to create sound artifacts.
>
> The reason computer systems are so hideously unreliable and error-prone
> today is exactly 'cause so many of its paid, putatively professional
> practitioners are ignorant of these principles. The sooner we put our
> understanding on a sound formal groundwork, the sooner we can get
> reliable information systems to the world.
>
> And yeah, I myself have a long way to go. But I appreciate being pointed
> in the right direction by those who are further down the road to a good
> understanding. Ignorance is not shameful, but the refusal to fill it in
> with understanding when you come to realize that ignorance _is_.
>
>
> Randall Schulz
>
Re: java enums more compact, flexible and obvious than scala's
On Mon, Jun 27, 2011 at 10:37 AM, mond ray <mondraymond [at] gmail [dot] com> wrote:
Re: java enums more compact, flexible and obvious than scala's
http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/Enumerator.html
Again, the deriving language feature would be great imo.
On 28/06/11 13:07, James Iry wrote:
Re: java enums more compact, flexible and obvious than scala's
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 28/06/11 03:37, mond ray wrote:
> Randall,
>
> We're all willing to learn... it's why we are on these groups and
> learning new languages.
>
> I can (almost literally) feel your passion - and that's good.
> Please however bear in mind that tone is important when one is
> trying to encourage others.
>
> As to enums, you never know, other FP languages might also have
> support for Enums. I had a quick check and they are part of
> Haskell, which I understand is a first class FP language. "Class
> Enum defines operations on sequentially ordered types."
> (http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelu...).
>
>
I don't want to get into a war of Scala vs Haskell. I'm just saying
> that this is not a purely Java language aspect.
This Haskell construct is very different to what is being demanded
here on this list. In particular, it is far far more useful, so if you
are going to request any language feature it is the more general
notion of "deriving" that haskell has.
Re: java enums more compact, flexible and obvious than scala's
Resent to whole list:
I'm pretty sure that Haskell's Enum isn't what you think it is.
I realise that a there's a few of us coming across as jerks on this
thread, but it's difficult to help more than already has been offered.
The SO question has what I personally would consider to be the best
scala-only solution (case objects) and then the thread has had the
additional suggestion that if you *really* want java enums, to use
those. Your rejection of the case objects as being "hacky"doesn't
really make much sense to me, but I guess that's a personal aesthetics
thing.
It's not obvious to me how the suggestion I mailed to you (case
objects in a list tupled with the sizes) doesn't solve your problem,
unless your complaint is purely that it takes more lines than java. If
that's the case, I totally agree - it does indeed take more lines.
On Mon, Jun 27, 2011 at 6:37 PM, mond ray wrote:
> Randall,
>
> We're all willing to learn... it's why we are on these groups and
> learning new languages.
>
> I can (almost literally) feel your passion - and that's good. Please
> however bear in mind that tone is important when one is trying to
> encourage others.
>
> As to enums, you never know, other FP languages might also have
> support for Enums. I had a quick check and they are part of Haskell,
> which I understand is a first class FP language. "Class Enum defines
> operations on sequentially ordered types."
> (http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelu...).
> I don't want to get into a war of Scala vs Haskell. I'm just saying
> that this is not a purely Java language aspect.
>
> Best regards
>
> Ray
>
> On 27 June 2011 15:40, Randall R Schulz wrote:
>> On Monday 27 June 2011, Clint Gilbert wrote:
>>> This is very true. Learning category theory and understanding
>>> algebra are definitely good things, but those sorts of reponses are
>>> very off-putting to newcomers, and aren't very helpful in the short-
>>> or medium-term.
>>>
>>> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>>> > I don't personally find responses along the lines of, "learn
>>> > category theory" and, "you should understand algebra" either leads
>>> > anyone towards enlightenment or welcomes them into the scala
>>> > community.
>>
>> These things are _fundamental_ to this profession. If you won't learn
>> them, you don't deserve the attribute "professional."
>>
>> And I feel that Scala is a tool for professionals, not dilettants. You
>> don't have to know all these things to start to use it, but you should
>> be willing to learn in order to understand why things are as they are
>> and to be able to create sound artifacts.
>>
>> The reason computer systems are so hideously unreliable and error-prone
>> today is exactly 'cause so many of its paid, putatively professional
>> practitioners are ignorant of these principles. The sooner we put our
>> understanding on a sound formal groundwork, the sooner we can get
>> reliable information systems to the world.
>>
>> And yeah, I myself have a long way to go. But I appreciate being pointed
>> in the right direction by those who are further down the road to a good
>> understanding. Ignorance is not shameful, but the refusal to fill it in
>> with understanding when you come to realize that ignorance _is_.
>>
>>
>> Randall Schulz
>>
>
Re: java enums more compact, flexible and obvious than scala's
Yes, it's OK. Thanks. We're all done bar the shouting.
On 27 June 2011 18:24, Alec Zorab wrote:
> Resent to whole list:
>
> I'm pretty sure that Haskell's Enum isn't what you think it is.
>
> I realise that a there's a few of us coming across as jerks on this
> thread, but it's difficult to help more than already has been offered.
> The SO question has what I personally would consider to be the best
> scala-only solution (case objects) and then the thread has had the
> additional suggestion that if you *really* want java enums, to use
> those. Your rejection of the case objects as being "hacky"doesn't
> really make much sense to me, but I guess that's a personal aesthetics
> thing.
>
> It's not obvious to me how the suggestion I mailed to you (case
> objects in a list tupled with the sizes) doesn't solve your problem,
> unless your complaint is purely that it takes more lines than java. If
> that's the case, I totally agree - it does indeed take more lines.
>
> On Mon, Jun 27, 2011 at 6:37 PM, mond ray wrote:
>> Randall,
>>
>> We're all willing to learn... it's why we are on these groups and
>> learning new languages.
>>
>> I can (almost literally) feel your passion - and that's good. Please
>> however bear in mind that tone is important when one is trying to
>> encourage others.
>>
>> As to enums, you never know, other FP languages might also have
>> support for Enums. I had a quick check and they are part of Haskell,
>> which I understand is a first class FP language. "Class Enum defines
>> operations on sequentially ordered types."
>> (http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Prelu...).
>> I don't want to get into a war of Scala vs Haskell. I'm just saying
>> that this is not a purely Java language aspect.
>>
>> Best regards
>>
>> Ray
>>
>> On 27 June 2011 15:40, Randall R Schulz wrote:
>>> On Monday 27 June 2011, Clint Gilbert wrote:
>>>> This is very true. Learning category theory and understanding
>>>> algebra are definitely good things, but those sorts of reponses are
>>>> very off-putting to newcomers, and aren't very helpful in the short-
>>>> or medium-term.
>>>>
>>>> On 06/27/2011 08:25 AM, Matthew Pocock wrote:
>>>> > I don't personally find responses along the lines of, "learn
>>>> > category theory" and, "you should understand algebra" either leads
>>>> > anyone towards enlightenment or welcomes them into the scala
>>>> > community.
>>>
>>> These things are _fundamental_ to this profession. If you won't learn
>>> them, you don't deserve the attribute "professional."
>>>
>>> And I feel that Scala is a tool for professionals, not dilettants. You
>>> don't have to know all these things to start to use it, but you should
>>> be willing to learn in order to understand why things are as they are
>>> and to be able to create sound artifacts.
>>>
>>> The reason computer systems are so hideously unreliable and error-prone
>>> today is exactly 'cause so many of its paid, putatively professional
>>> practitioners are ignorant of these principles. The sooner we put our
>>> understanding on a sound formal groundwork, the sooner we can get
>>> reliable information systems to the world.
>>>
>>> And yeah, I myself have a long way to go. But I appreciate being pointed
>>> in the right direction by those who are further down the road to a good
>>> understanding. Ignorance is not shameful, but the refusal to fill it in
>>> with understanding when you come to realize that ignorance _is_.
>>>
>>>
>>> Randall Schulz
>>>
>>
>
Re: java enums more compact, flexible and obvious than scala's
Tell that to Linus Thorvalds. Or Alan Kay. Or John McCarty. Or Donald Knuth. Or Martin Fowler. Or Joshua Bloch. Or Rich Hickey. Or ...
If the list looks somewhat random it is because it is. There are so ridiculously many great developers and computer scientists that don't really care about category theory. The vast majority don't. That's not to say it isn't useful, but claiming that you don't deserve the attribute "professional" if you don't learn "these things" is simply absurd. Anyone who claims that has a lot to prove.
Also, somehow it seems that people like Simon Peyton Jones, Phil Wadler, John Hughes etc manage to know a thing or two about these things without being jerks about it, so clearly it is possible. (And some people on this list, like Greg Meredith, Jason Zaugg and others, show that this is even possible within the Scala community).
Disclaimer:Obviously I can't speak for any of the names dropped above. My apologies if I'm mistaken about any of them. Also I don't generally find appeal to authority to be a convincing argument. But let me reiterate that I'm not claiming these things are not useful, I'm only objecting to the quoted assertion and to the manners of some people on this mailing list.
Cheers,Daniel
Re: java enums more compact, flexible and obvious than scala's
I'm not saying this was necessarily the right choice (indeed, right wrt to what criterion?), just explaining what the issues are.
Cheers
-- Martin
Since it covers so much more
On Mon, Jun 27, 2011 at 5:40 PM, Randall R Schulz <rschulz [at] sonic [dot] net> wrote:
--
----------------------------------------------
Martin Odersky
Prof., EPFL and CEO, Typesafe
PSED, 1015 Lausanne, Switzerland
Tel. EPFL: +41 21 693 6863
Tel. Typesafe: +41 21 691 4967
Re: java enums more compact, flexible and obvious than scala's
- Josh
On Mon, Jun 27, 2011 at 12:19 PM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
Re: java enums more compact, flexible and obvious than scala's
Like Tony I enjoy learning new things - that's why I'm trying Scala.
Thanks all for the support as well as the ideas.
Best regards
Ray
On 27 June 2011 15:22, Clint Gilbert <clint_gilbert [at] hms [dot] harvard [dot] edu> wrote:
Re: java enums more compact, flexible and obvious than scala's
As I mentioned directly to Ray earlier, I think this stems from the
fact that java enums are very odd little beasts which people have
built very language-specific patterns around. Either Java enums get
added to the language (which I think is bad, because they're not very
general at all) or people just use Java to generate their enums (which
lets fans of the pattern carry on using it) or people use case
objects, as is generally considered idiomatic.
I personally have never felt the need to use an enum since I moved
from C, so I can't personally say which is preferable.
Regards
On Mon, Jun 27, 2011 at 1:25 PM, Matthew Pocock
wrote:
>>
>> We see this issue every few weeks by the way.
>
> Yes, which tells us one of: we don't have the right documentation; there is
> a genuine issue that needs addressing; the 'wrong' people are trying to use
> scala. As scala is a general purpose programming that has every intention of
> being main-stream, I think that rules the 3rd option out. I don't personally
> find responses along the lines of, "learn category theory" and, "you should
> understand algebra" either leads anyone towards enlightenment or welcomes
> them into the scala community.
> Matthew
>>
>>
>> - --
>> Tony Morris
>> http://tmorris.net/
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk4ITxYACgkQmnpgrYe6r60uPgCglGLFWWXEg+1fPxBB/MOM5eMZ
>> 3SsAnjkyZ82XAfEWIM0EOzuruWK2FQYX
>> =eLSM
>> -----END PGP SIGNATURE-----
>>
>
>
>
> --
> Dr Matthew Pocock
> Visitor, School of Computing Science, Newcastle University
> mailto: turingatemyhamster [at] gmail [dot] com
> gchat: turingatemyhamster [at] gmail [dot] com
> msn: matthew_pocock [at] yahoo [dot] co [dot] uk
> irc.freenode.net: drdozer
> (0191) 2566550
>
Re: java enums more compact, flexible and obvious than scala's
Why's it trite? you're trying to shoehorn a java idiom into scala and
then complaining that scala doesn't support it. There is already a
well defined and widely used system for java idioms (it's called
"java").
No-one is stopping you using it.
On Mon, Jun 27, 2011 at 10:36 AM, Tony Morris wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 27/06/11 19:29, mond ray wrote:
>> Indeed Alec, though that's a little trite, eh?
>>
>> Wouldn't it also be nice to have a Scala solution that is clear,
>> simple and at least as usable as the Java type? If it's better
>> done with some idiomatic Scala, then that's fine.
>>
>> I know it must be torture Tony, but it's a bit much to ask that I
>> (and many other Java migrants) need to go away and study the
>> theory of algebraic data types before making any further
>> meaningful comment.
>
> I'm not sure why you ask that, but no, it's not a bit much to ask. Why
> should one not understand algebra before expecting one's comment to be
> taken seriously on algebra? That only makes sense to me. Besides,
> learning is fun.
>
> We see this issue every few weeks by the way.
>
>>
>> Shouldn't the smart folks be making the appropriate idiomatic usage
>> accessible to the rest of us?
> There is no "idiomatic usage." This is simply an exhibition of an
> arbitrary bias.
>
> Always happy to teach algebra[ic data types], any time and (almost)
> any forum.
>
>
> - --
> Tony Morris
> http://tmorris.net/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk4ITxYACgkQmnpgrYe6r60uPgCglGLFWWXEg+1fPxBB/MOM5eMZ
> 3SsAnjkyZ82XAfEWIM0EOzuruWK2FQYX
> =eLSM
> -----END PGP SIGNATURE-----
>
>
Re: java enums more compact, flexible and obvious than scala's
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This isn't a bad solution, especially for simple cases. Using Java
enums from Scala works quite well. I got away from that approach due to
the problems I had with the Eclipse Scala plugin and mixed Scala/Java
projects. The Scala plugin is much happier with a 100% Scala project,
which is why I started looking for an all-Scala solution.
On 06/26/2011 08:03 PM, Alec Zorab wrote:
> I'm pretty sure no-one has confiscated your java compiler. If you
> desperately, desperately want java enums, make them in java.
>
> Problem solved?
>
> On Mon, Jun 27, 2011 at 12:22 AM, Tony Morris wrote:
>> There will always be several (infinite) ways to define an algebraic data
>> type, even in Java:
>> interface Boolean { X ifelse(X t, X f); }
>>
>> No, it isn't blindingly clear. It's a distraction.
>>
>> On 27/06/11 08:40, Ken McDonald wrote:
>>> I took a look at the stackoverflow posting mentioned above. I've also
>>> taken to using case objects for my Enums, though not nearly in as
>>> sophisticated a manner--but then, my needs haven't yet been that complex.
>>>
>>> But all of this different experimentation that people are doing around
>>> how to do enums is making one thing blindingly clear to me:
>>>
>>> SCALA NEEDS A REAL ENUM TYPE.
>>>
>>> The fact that so many people are trying so many different things is
>>> clear evidence that the current "solution" is not that as far as many
>>> users are concerned. In addition, it adds a (moderately high--I have
>>> to look up how to define Enums every time I do it the "official" way)
>>> hurdle for Java programmers to clear when they start with Scala, and
>>> that hurdle comes pretty quickly--after all, enums are really quite basic.
>>>
>>> While I respect the desire of the Scala team to keep the language as
>>> conceptually lean as possible, I think it is time to at least talk
>>> about adding in a genuine enumerated type facility, given that the
>>> experimentation people are doing indicates the recommended solution is
>>> not satisfactory.
>>>
>>> Comments?
>>>
>>> Thanks,
>>> Ken
>>
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAk4H6gwACgkQ0GFaTS4nYxs8pgCfRapIp8+undCYAE9Wn1L2X5gq
kasAnikHDTrzTFNHTVzTP7IvgE5Cs/8S
=WcEb
-----END PGP SIGNATURE-----
Re: java enums more compact, flexible and obvious than scala's
The problem is disproportionate attention to syntactic/aesthetic desires
on arbitrary biases. Coaching out of the bubble is a tough task.
On 27/06/11 10:03, Alec Zorab wrote:
> I'm pretty sure no-one has confiscated your java compiler. If you
> desperately, desperately want java enums, make them in java.
>
> Problem solved?
>
> On Mon, Jun 27, 2011 at 12:22 AM, Tony Morris wrote:
>> There will always be several (infinite) ways to define an algebraic data
>> type, even in Java:
>> interface Boolean { X ifelse(X t, X f); }
>>
>> No, it isn't blindingly clear. It's a distraction.
>>
>> On 27/06/11 08:40, Ken McDonald wrote:
>>> I took a look at the stackoverflow posting mentioned above. I've also
>>> taken to using case objects for my Enums, though not nearly in as
>>> sophisticated a manner--but then, my needs haven't yet been that complex.
>>>
>>> But all of this different experimentation that people are doing around
>>> how to do enums is making one thing blindingly clear to me:
>>>
>>> SCALA NEEDS A REAL ENUM TYPE.
>>>
>>> The fact that so many people are trying so many different things is
>>> clear evidence that the current "solution" is not that as far as many
>>> users are concerned. In addition, it adds a (moderately high--I have
>>> to look up how to define Enums every time I do it the "official" way)
>>> hurdle for Java programmers to clear when they start with Scala, and
>>> that hurdle comes pretty quickly--after all, enums are really quite basic.
>>>
>>> While I respect the desire of the Scala team to keep the language as
>>> conceptually lean as possible, I think it is time to at least talk
>>> about adding in a genuine enumerated type facility, given that the
>>> experimentation people are doing indicates the recommended solution is
>>> not satisfactory.
>>>
>>> Comments?
>>>
>>> Thanks,
>>> Ken
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
Re: java enums more compact, flexible and obvious than scala's
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
type Three = Option[Unit]
type FlatFileHeaderMapping = (Three /* want more? */, Int)
Syntactic compactness is chronically overrated. You want computational
compactness.
On 27/06/11 04:31, mond ray mond wrote:
> Sorry for what might seem like a trolling subject line, but this is
> a bit of a shocker since I usually find elegance in Scala rather
> than Java.
>
> I am dealing with some legacy record layouts and in Java I have
> something like this
>
> public enum FlatFileHeaderMapping {
>
> FIELD1(1), FIELD2(5), // And loads more, elided for the sake of
> (your) sanity FIELDN(4)
>
> public final int fieldSize;
>
> private FlatFileHeaderMapping(final int fieldSize) { this.fieldSize
> = fieldSize; } }
>
> which I can then use to place each line into a map:
>
> public ProcessLegacyRecord(final String inputString) {
>
> // Specify LinkedHashMap to retain insertion order
> LinkedHashMap headerValuesMap;
>
> headerValuesMap = new LinkedHashMap String>(); int currPos = 0; for (FlatFileHeaderMapping m :
> FlatFileHeaderMapping.values()) { int endPos = currPos +
> m.fieldSize; String HeaderValue = inputString.substring(currPos,
> endPos); headerValuesMap.put(m, HeaderValue); currPos = endPos; }
> }
>
> and later access the keys in the map via this enum:
>
> String field1 = headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>
> Enumeration does not have these qualities as far as I can see, and
> case classes are not ordered like the enum values - so cannot be
> used to match a record layout as shown above. At least not without
> the support of an ordered collection.
>
> I could be missing something obvious, hence the question!
>
> Or please feel free to tear up the enum aspect and suggest a more
> functional, Scala-esque way to deal with fixed length inputs in a
> type safe / symbolic / elegant way!
>
> Thanks
>
> Ray
>
> PS I also posted a shorter form of this question to SO
> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
>
- --
>
Tony Morris
http://tmorris.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4HriMACgkQmnpgrYe6r63IQQCfauE6von3YqeFsvcscQnhEGSx
2LgAnRNdE8UJznf/UAF2gR9kTmtT/OUC
=V7No
-----END PGP SIGNATURE-----
Re: java enums more compact, flexible and obvious than scala's
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
type Three = Option[Boolean] // correction
On 27/06/11 08:09, Tony Morris wrote:
>
> type Three = Option[Unit] type FlatFileHeaderMapping = (Three /*
> want more? */, Int)
>
> Syntactic compactness is chronically overrated. You want
> computational compactness.
>
> On 27/06/11 04:31, mond ray mond wrote:
>> Sorry for what might seem like a trolling subject line, but this
>> is a bit of a shocker since I usually find elegance in Scala
>> rather than Java.
>
>> I am dealing with some legacy record layouts and in Java I have
>> something like this
>
>> public enum FlatFileHeaderMapping {
>
>> FIELD1(1), FIELD2(5), // And loads more, elided for the sake of
>> (your) sanity FIELDN(4)
>
>> public final int fieldSize;
>
>> private FlatFileHeaderMapping(final int fieldSize) {
>> this.fieldSize = fieldSize; } }
>
>> which I can then use to place each line into a map:
>
>> public ProcessLegacyRecord(final String inputString) {
>
>> // Specify LinkedHashMap to retain insertion order
>> LinkedHashMap<FlatFileHeaderMapping, String> headerValuesMap;
>
>> headerValuesMap = new LinkedHashMap<FlatFileHeaderMapping,
>> String>(); int currPos = 0; for (FlatFileHeaderMapping m :
>> FlatFileHeaderMapping.values()) { int endPos = currPos +
>> m.fieldSize; String HeaderValue = inputString.substring(currPos,
>> endPos); headerValuesMap.put(m, HeaderValue); currPos = endPos;
>> } }
>
>> and later access the keys in the map via this enum:
>
>> String field1 =
>> headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>
>> Enumeration does not have these qualities as far as I can see,
>> and case classes are not ordered like the enum values - so
>> cannot be used to match a record layout as shown above. At least
>> not without the support of an ordered collection.
>
>> I could be missing something obvious, hence the question!
>
>> Or please feel free to tear up the enum aspect and suggest a more
>> functional, Scala-esque way to deal with fixed length inputs in a
>> type safe / symbolic / elegant way!
>
>> Thanks
>
>> Ray
>
>> PS I also posted a shorter form of this question to SO
>>
> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-scala-that-has-an-extra-field
>
>
>
- --
>
>
Tony Morris
http://tmorris.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk4HsKEACgkQmnpgrYe6r61bGACfWbJfwlgSlQ6nSd/8xRk/F3Ne
OuoAnR3Bgn8HUU6o2RL2gmb2JiKFnMu9
=udBV
-----END PGP SIGNATURE-----
Re: java enums more compact, flexible and obvious than scala's
or:
yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)
or you could use an implicit conversion to add logic to your simple scala enumeration.
Am 26.06.2011 20:31, schrieb mond ray mond:
Re: java enums more compact, flexible and obvious than scala's
I see where you're going on the case class but doesn't this result in
a huge number of class definitions - 1 per field?
Could you flesh out the implicit idea a little more? I would like to
grok the magic ;-)
Thanks
Ray
On Sunday, 26 June 2011, HamsterofDeath wrote:
>
>
>
>
>
>
>
> to add an ordering: List(yourcaseclassA(1),
> yourcaseclassB(23),yourcaseclassC(17),...)
>
> or:
>
> yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)
>
> or you could use an implicit conversion to add logic to your simple
> scala enumeration.
>
> Am 26.06.2011 20:31, schrieb mond ray mond:
>
>
> Sorry for what might seem like a trolling subject line, but
> this is a bit of a shocker since I usually find elegance in
> Scala rather than Java.
>
>
> I am dealing with some legacy record layouts and in Java I
> have something like this
>
>
> public enum FlatFileHeaderMapping {
>
>
> FIELD1(1),
> FIELD2(5),
> // And loads more, elided for the sake of (your) sanity
> FIELDN(4)
>
>
> public final int fieldSize;
>
>
> private FlatFileHeaderMapping(final int fieldSize) {
> this.fieldSize = fieldSize;
> }
> }
>
>
> which I can then use to place each line into a map:
>
>
> public ProcessLegacyRecord(final String inputString) {
>
>
> // Specify LinkedHashMap to retain insertion order
> LinkedHashMap
> headerValuesMap;
>
>
> headerValuesMap = new
> LinkedHashMap();
> int currPos = 0;
> for (FlatFileHeaderMapping m :
> FlatFileHeaderMapping.values()) {
> int endPos = currPos + m.fieldSize;
> String HeaderValue =
> inputString.substring(currPos, endPos);
> headerValuesMap.put(m, HeaderValue);
> currPos = endPos;
> }
> }
>
>
> and later access the keys in the map via this enum:
>
>
> String field1 =
> headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>
>
> Enumeration does not have these qualities as far as I can
> see, and case classes are not ordered like the enum values - so
> cannot be used to match a record layout as shown above. At least
> not without the support of an ordered collection.
>
>
> I could be missing something obvious, hence the question!
>
>
> Or please feel free to tear up the enum aspect and suggest a
> more functional, Scala-esque way to deal with fixed length
> inputs in a type safe / symbolic / elegant way!
>
>
> Thanks
>
>
> Ray
>
>
> PS I also posted a shorter form of this question to SO
> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
>
>
>
>
>
>
Re: java enums more compact, flexible and obvious than scala's
On Sunday 26 June 2011, mond ray wrote:
> I see where you're going on the case class but doesn't this result in
> a huge number of class definitions - 1 per field?
If you're worried about JVM-level class proliferation, Scala's not the
language for you! Every closure / function literal in Scala is
implemented as a class.
> Could you flesh out the implicit idea a little more? I would like to
> grok the magic ;-)
>
> Thanks
>
> Ray
Randall Schulz
Re: java enums more compact, flexible and obvious than scala's
I was thinking about classes visible in scala. This feels like you
semi-flamed me which ain't friendly Randall.
On Sunday, 26 June 2011, Randall R Schulz wrote:
> On Sunday 26 June 2011, mond ray wrote:
>> I see where you're going on the case class but doesn't this result in
>> a huge number of class definitions - 1 per field?
>
> If you're worried about JVM-level class proliferation, Scala's not the
> language for you! Every closure / function literal in Scala is
> implemented as a class.
>
>
>> Could you flesh out the implicit idea a little more? I would like to
>> grok the magic ;-)
>>
>> Thanks
>>
>> Ray
>
>
> Randall Schulz
>
Re: java enums more compact, flexible and obvious than scala's
Am 26.06.2011 21:09, schrieb mond ray:
> I see where you're going on the case class but doesn't this result in
> a huge number of class definitions - 1 per field?
not necessarily.
val first = youronlycaseclass(1)
val second = youronlycaseclass(4)
List(first, second)
> Could you flesh out the implicit idea a little more? I would like to
> grok the magic ;-)
>
> Thanks
>
> Ray
>
> On Sunday, 26 June 2011, HamsterofDeath wrote:
>>
>>
>>
>>
>>
>>
>> to add an ordering: List(yourcaseclassA(1),
>> yourcaseclassB(23),yourcaseclassC(17),...)
>>
>> or:
>>
>> yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)
>>
>> or you could use an implicit conversion to add logic to your simple
>> scala enumeration.
>>
>> Am 26.06.2011 20:31, schrieb mond ray mond:
>>
>>
>> Sorry for what might seem like a trolling subject line, but
>> this is a bit of a shocker since I usually find elegance in
>> Scala rather than Java.
>>
>>
>> I am dealing with some legacy record layouts and in Java I
>> have something like this
>>
>>
>> public enum FlatFileHeaderMapping {
>>
>>
>> FIELD1(1),
>> FIELD2(5),
>> // And loads more, elided for the sake of (your) sanity
>> FIELDN(4)
>>
>>
>> public final int fieldSize;
>>
>>
>> private FlatFileHeaderMapping(final int fieldSize) {
>> this.fieldSize = fieldSize;
>> }
>> }
>>
>>
>> which I can then use to place each line into a map:
>>
>>
>> public ProcessLegacyRecord(final String inputString) {
>>
>>
>> // Specify LinkedHashMap to retain insertion order
>> LinkedHashMap
>> headerValuesMap;
>>
>>
>> headerValuesMap = new
>> LinkedHashMap();
>> int currPos = 0;
>> for (FlatFileHeaderMapping m :
>> FlatFileHeaderMapping.values()) {
>> int endPos = currPos + m.fieldSize;
>> String HeaderValue =
>> inputString.substring(currPos, endPos);
>> headerValuesMap.put(m, HeaderValue);
>> currPos = endPos;
>> }
>> }
>>
>>
>> and later access the keys in the map via this enum:
>>
>>
>> String field1 =
>> headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>>
>>
>> Enumeration does not have these qualities as far as I can
>> see, and case classes are not ordered like the enum values - so
>> cannot be used to match a record layout as shown above. At least
>> not without the support of an ordered collection.
>>
>>
>> I could be missing something obvious, hence the question!
>>
>>
>> Or please feel free to tear up the enum aspect and suggest a
>> more functional, Scala-esque way to deal with fixed length
>> inputs in a type safe / symbolic / elegant way!
>>
>>
>> Thanks
>>
>>
>> Ray
>>
>>
>> PS I also posted a shorter form of this question to SO
>> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
>>
>>
>>
>>
>>
>>
Re: java enums more compact, flexible and obvious than scala's
Thanks for your patience!
Ray
On 26 June 2011 21:18, HamsterofDeath <h-star [at] gmx [dot] de> wrote:
Re: java enums more compact, flexible and obvious than scala's
implicit def enableSomeMethods(yourenumvalue:YourEnumType) = new {
//your methods here. if you need to fake an attribute, you can do:
def getAttrib = yourenumvalue match {
case a => 1
case b => 25
//and so on
}
}
i don't know how much you know about implicit conversions, but this
piece of code can be imported and then you can do:
yourEnumValue.yourMethodDeclaredInThePartAbove
(this email has been written with the screen being behind my back, so i
didn not see much. going to plac alice: madness returns on my
3dprojector (or whatever it's called in english)
it'll be slower than the case class solution, but if that's not a
problem, go ahead.
Am 26.06.2011 21:09, schrieb mond ray:
> I see where you're going on the case class but doesn't this result in
> a huge number of class definitions - 1 per field?
>
> Could you flesh out the implicit idea a little more? I would like to
> grok the magic ;-)
>
> Thanks
>
> Ray
>
> On Sunday, 26 June 2011, HamsterofDeath wrote:
>>
>>
>>
>>
>>
>>
>> to add an ordering: List(yourcaseclassA(1),
>> yourcaseclassB(23),yourcaseclassC(17),...)
>>
>> or:
>>
>> yourCaseClass(num:Int, ord:Int = OrderingAtomicObject.nextInt)
>>
>> or you could use an implicit conversion to add logic to your simple
>> scala enumeration.
>>
>> Am 26.06.2011 20:31, schrieb mond ray mond:
>>
>>
>> Sorry for what might seem like a trolling subject line, but
>> this is a bit of a shocker since I usually find elegance in
>> Scala rather than Java.
>>
>>
>> I am dealing with some legacy record layouts and in Java I
>> have something like this
>>
>>
>> public enum FlatFileHeaderMapping {
>>
>>
>> FIELD1(1),
>> FIELD2(5),
>> // And loads more, elided for the sake of (your) sanity
>> FIELDN(4)
>>
>>
>> public final int fieldSize;
>>
>>
>> private FlatFileHeaderMapping(final int fieldSize) {
>> this.fieldSize = fieldSize;
>> }
>> }
>>
>>
>> which I can then use to place each line into a map:
>>
>>
>> public ProcessLegacyRecord(final String inputString) {
>>
>>
>> // Specify LinkedHashMap to retain insertion order
>> LinkedHashMap
>> headerValuesMap;
>>
>>
>> headerValuesMap = new
>> LinkedHashMap();
>> int currPos = 0;
>> for (FlatFileHeaderMapping m :
>> FlatFileHeaderMapping.values()) {
>> int endPos = currPos + m.fieldSize;
>> String HeaderValue =
>> inputString.substring(currPos, endPos);
>> headerValuesMap.put(m, HeaderValue);
>> currPos = endPos;
>> }
>> }
>>
>>
>> and later access the keys in the map via this enum:
>>
>>
>> String field1 =
>> headerValuesMap.get(FlatFileHeaderMapping.FIELD1);
>>
>>
>> Enumeration does not have these qualities as far as I can
>> see, and case classes are not ordered like the enum values - so
>> cannot be used to match a record layout as shown above. At least
>> not without the support of an ordered collection.
>>
>>
>> I could be missing something obvious, hence the question!
>>
>>
>> Or please feel free to tear up the enum aspect and suggest a
>> more functional, Scala-esque way to deal with fixed length
>> inputs in a type safe / symbolic / elegant way!
>>
>>
>> Thanks
>>
>>
>> Ray
>>
>>
>> PS I also posted a shorter form of this question to SO
>> http://stackoverflow.com/questions/6473445/how-do-i-create-an-enum-in-sc...
>>
>>
>>
>>
>>
>>