Page 2 - Ruby Section

No, it's not pretty clear.

If there's no model, it's not MVC, simple as that.

You can say what you like, it doesn't make it true, and looks like it's one of those cases.

I'd like to clarify this: just because the model is handled outside of the system (or handled for you) doesn’t mean that it's not part of the design. RoR fits with MVC, end of story .

By your definition Cocoa apps may not be MVC because of bindings and such — yet MVC is mentioned to some degree in every Cocoa book and Intro that I've read. You have utils to handle the model for you, and you may choose some existing models. It just works.

The claim seems very far-fetched and has nothing to do with the nature of design patterns as I understand them. What’s important is that a system is composed in a certain way. Not that you have to do something manually or internally.

Think separation.

Take care ,

Mark.

the model isn't necessarily anything to do with a RDBMS, it's just wherever the data is stored, which in this case is a bunch of ruby objects. The fact that the data originally comes from a database and will be going back there sometime is the layer below.

Yeah, but it's still modelling how it will be stored (whatever lies underneath it, be it Postgres or CSV, or even flatfile). Rails isn't really mvc since you skip the modelling stage and entrust activerecord to build an internal structure for you (I believe this is what you were calling a model, Mark). I suppose it comes down to personal preference as to whether you regard that as a model. personally, unless it was manually modelled, i wouldn't.

Welcome back LinuxPenguin

Thank you, xlordt

I don't see how you can skip the Model stage by doing it elsewhere. In the same way that you're still creating a View if you choose to use something like Interface Builder* .

Modeling data within a system has about as much to do with MVC as classes have to do with OOP — that is to say not a lot .

I think it really comes down to what a design pattern is, and by extension what MVC is. The only reason to call anything MVC is because it uses this design pattern.

I'll reiterate: a system doesn't have to work the way you want for it to be MVC, the separation is there. Automation is another abstraction entirely.

Rails fits the bill, so it is MVC *shug*. It's really a mood point to claim otherwise don't you think .

Take care,

Mark.

* Interface builder will also create a usable Model for you. In fact it often amazed me how much you can actually do without moving into Xcode.

I missed you baby anyways...


To answer the question of a new forum, I think it would be better to keep it as it is for now.. till it really bug's everyone.

damn LinuxPenguin you always seem to get me derepped

You manage just fine without my help, maybe those trolling classes really paid off

Nice to have you back.

@Mark: *shrug* could be argued either way. And like you said, moot point.

hahaha.. i never left sister

While I think it's probably a bit early for it, I don't see a problem with adding a Ruby section. While it's true there hasn't been a huge amount of discussion of it yet in OPL, there certainly has been more than for many other languages. Also, citing the lack of activity on OPL for a given language as a reason not to have a separate group for it can become a self-fullfilling prophecy (no, not one made by Jecel Assumpcao about prototype-based OOP languages , I mean one that leads to it's own predicted results), as readers who might be interested in the language might get discouraged by the apparent lack of interest in it here. Conversely, having a a group for the language might jump-start interest in it on this board - just look at the how simply having the OPL group has spurred activity in several languages which were almost unknown here a short while ago.

Besides, I've been sadly lax in following up on Ruby myself, and it would give me an excuse to learn more about it

I can't see how anyone who has used more than a handful of languages could say that they are all the same; if that were the case, no one would have ever used anything except Assembler in the first place. The language being used can have a tremendous impact on how you approach a problem; you would not write in, say, Java, the same way you would in C, nor would you write in Haskell the same way you would in Smalltalk. The viewpoints different languages give you can be radically different - but at the same time, they can also clarify the perspectives you hold in other languages. Also, some languages support or facilitate approaches which might be cumbersome or impractical in others - try using Continuation Passing Style in C, for example, or conversely, directly accessing a memory-mapped device in Scheme or Java, to see what I mean.

I know that I'm seen as a bit of a kook by some folks for the whole 'Scheme is the Red Pill' thing, but that's because it comes across to most people as language advocacy. While I won't deny that this is one part of it, is not the main point I'm trying to make. The real advantage in learning Scheme - or other unconventional languages like Self or FORTH or APL - is in how they open up your perspective, not only in those languages but in the ones you use for day to day programing as well. In other words, as Eric Raymond once said, learning Lisp doesn't just make you a Lisp programer, it can also make you a better C programmer. And while (In my decidely biased and arrogant opinion) the Lisp languages are particularly valuable in this way, it is still just as true of other unconventional notations. Free Your Mind.

OK, why not start a group for haskell then - maybe it would kick start interest in my own current favourite...

IMO ruby will need a group when this one is mainly questions about ruby.

You hit the nail on the head...



For the meantime this will do. It would be nice to see them put some other languages in the description for this forum though

I think its better this way... keep it in this forum till the language gets a bit more popular here at devshed.