headers
Jan E. | 1 Jul 2012 02:19

Re: Accessor Methods with a Twist

Doug Jolley wrote in post #1066813:
> My understanding was that when I did:
>
>> person_1 = Person.new 'Doug'
>
> the left-hand-side was a local variable.  After reading your response, I
> thought that maybe it isn't.  Maybe it's something else that would be
> available in a module.  I used the following code (which draws heavily
> on your example) to test this hypothesis:

It *is* a local variable. There are four types of variables in Ruby:

- local variables beginning with a lowercase letter or an underscore
- instance variables beginning with a single " <at> "
- class variables beginning with " <at>  <at> "
- global variables beginning with a "$"

All four have completely different features and purposes.

A local variable is a temporary variable for a specific context (mostly 
a method). It isn't visible to other contexts, which is why your code 
doesn't work.

Instance variables are persistent variables bound to a specific object. 
They carry the properties of this object (like the name). You can only 
access it from the context of the object -- but of course you can pass 
the value to the outside world through getter methods.

A class variable can be accessed from the class it was created by as 
well as every subclass and every instance of those classes. You can use
(Continue reading)

Permalink | Reply | 5 comments |
headers
Doug Jolley | 1 Jul 2012 03:37

Re: Accessor Methods with a Twist

Thanks again for another very thorough response.

I'm afraid that I'm going to have to think about all that you have said.
As you probably have recognized, we are pushing the envelope of my
capabilities.

The thing is this: I have this object (i.e., an instance of a class).
This particular instance is used for a multitude of purposes.  Among
them is that the instance is needed by several methods contained in a
module.  The methods of the module will never require any other
instance.  They always require only this particular instance.  I guess I
could pass the instance to each of these methods that needs it as an
argument.  Since there are so many of the methods of the module that
need the instance, I was hoping that there might be another more
sanitary way of doing it.

From what you have said, I suspect that I am having this problem because
there is a major problem with the underlying structure of my code.  I'm
not sure that I am going to be able to figure out what the problem is
and fix it.

Thanks so much for your help.

         ... doug

--

-- 
Posted via http://www.ruby-forum.com/.
Permalink | Reply | 4 comments |
headers
Ryan Davis | 1 Jul 2012 04:49
Gravatar

Re: Accessor Methods with a Twist


On Jun 30, 2012, at 18:37 , Doug Jolley wrote:

> The thing is this: I have this object (i.e., an instance of a class).
> This particular instance is used for a multitude of purposes.

You should stop here.

Your class should generally do one thing and do it well.

Don't use modules to mix in functionality until you understand your underlying design _thoroughly_.
Until then, you're just going to shoot yourself in the foot.
Permalink | Reply | 3 comments |
headers
Tomas R. | 1 Jul 2012 07:01

Real time collaborative editing

I was just thinking on create a little app for real time collaborative
editing with version control, something like GDocs. The thing is I'm not
an expert programmer and dont know very well how to affort this, I was
thinking at first converting the file document (document, spreadsheet,
etc) into html code and then beeing able to edit and user version
control since i dont think that should be posible on a XLS file for
example. I also found Google Mobwrite project but it's design to work on
python or as a java client, what you guys suggest me

--

-- 
Posted via http://www.ruby-forum.com/.
Permalink | Reply | 1 comment |
headers
anaray anaray | 1 Jul 2012 07:02

Re: ruby performance

Thanks Bob for your valuable input. I think then in this case, Ruby with
MRI is a wrong choice. This was just preliminary test, my work involves
lots String, array processing, which involves huge data-set.

Recently I tried Ruby, and really loved the language, so i thought of
using it in my next work.

I am going to try Jruby

Thanks

--

-- 
Posted via http://www.ruby-forum.com/.
Permalink | Reply | 2 comments |
headers
anaray anaray | 1 Jul 2012 07:05

Re: ruby performance

Yes, I am Ruby newbie :)
Later after posting this, i tried the Ruby way of iteration, but it also 
didn't help much, I am well short of requirement

Thanks

Jan E. wrote in post #1066782:
> Hi,
>
> If performance is what you're after, I think Ruby is simply the wrong
> language.
>
> You can try different Ruby implementations, you can optimize your code a
> bit, but you'll never come close to the 8 seconds of Java.
>
> I'm not even sure if you've actually adapted Ruby, because the code
> above rather looks like you're translating Java code into Ruby.

--

-- 
Posted via http://www.ruby-forum.com/.
Permalink | Reply | 0 comments |
headers
smoothedatol412 @gmail.com | 1 Jul 2012 08:46

Re: Neworking side of ruby

Thank you to all who have replied to this post, I have alot of work 
ahead of me and I post any questions I have to this forum. Thank you 
again.

--

-- 
Posted via http://www.ruby-forum.com/.
Permalink | Reply | 0 comments |
headers
sto.mar | 1 Jul 2012 10:02
Picon
Gravatar

Re: Array index confusion

A late update: I submitted a patch for the documentation,
see <https://bugs.ruby-lang.org/issues/6680>

--

-- 
<https://github.com/stomar/>
Permalink | Reply | 0 comments |
headers
Jan E. | 1 Jul 2012 10:19

Re: Accessor Methods with a Twist

Doug Jolley wrote in post #1066832:
> The thing is this: I have this object (i.e., an instance of a class).
> This particular instance is used for a multitude of purposes.  Among
> them is that the instance is needed by several methods contained in a
> module.  The methods of the module will never require any other
> instance.  They always require only this particular instance.  I guess I
> could pass the instance to each of these methods that needs it as an
> argument.  Since there are so many of the methods of the module that
> need the instance, I was hoping that there might be another more
> sanitary way of doing it.

I don't see why you want to use a module for this. I'd rather use a 
*class* and pass the object to the initialize method. You can then save 
it in an instance variable and use it in any method.

For example:

# create a database connection
database = Database.new username: 'root', passwort: '123456'
# create an instance of PictureArchive and pass it the database object
picture_archive = PictureArchive.new database
# the picture archive can now use the database connection
my_holiday_pictures = picture_archive.search year: 2011

I think you should only use modules for three things: as a namespace, as 
a collection of "static" functions (like Math) or as mixin to provide 
methods to classes (like Enumerable).

Your description doesn't fit any of these cases. But again: If you tell 
use what you actually want to do, we can think about alternative
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Wong | 1 Jul 2012 10:39

[ANN] local-openid 0.3.0 - Single User, Ephemeral OpenID Provider

local-openid allows users with shell accounts on servers to authenticate
with OpenID consumers by editing a YAML file in their home directory
instead of authenticating through HTTP/HTTPS.

* http://bogomips.org/local-openid/
* local.openid <at> librelist.org
* git://bogomips.org/local-openid.git
* http://bogomips.org/local-openid/NEWS.atom.xml

Changes:

This release brings a major compatibility improvement
from Lionel Elie Mamane:

  The OpenID provider identifier and user identifier are now
  distinct and compliant with the OpenID 2.0 specification.

  The user identifier is unchanged: http://${HOST}/
  The provider identifier (and provider endpoint URL) is now
  http://${HOST}/provider

If you were not able to get local-openid working with a certain site in
the past, this version may work for you.  Please report any
compatibility problems to local.openid <at> librelist.org and hopefully
somebody can help.  Unreported issues can never be fixed.

The Sinatra dependency is relaxed to allow any 1.x version
(tested with 1.3.2 and 1.0.0).

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane