[#397988] Help with sqlite3 please — Kaye Ng <lists@...>

I'm on Windows 7 Ultimate, 64-bit

18 messages 2012/08/03
[#397989] Re: Help with sqlite3 please — Chris Hulan <chris.hulan@...> 2012/08/03

sqlite is not ruby, so you should look for a sqlite group ;)

[#397990] Re: Help with sqlite3 please — Kaye Ng <lists@...> 2012/08/03

> However it looks like you have 'SQL' at the beginning of your CREATE

[#398031] Gem install or usage problem in shared environment — Tom Moulton <lists@...>

I am moving to a Westhost shared CPanel account and I am trying to set

17 messages 2012/08/04
[#398077] Re: Gem install or usage problem in shared environment — Tom Moulton <lists@...> 2012/08/06

I got a solution from WestHost and it may help others:

[#398086] Re: Gem install or usage problem in shared environment — Ryan Davis <ryand-ruby@...> 2012/08/07

[#398088] Re: Gem install or usage problem in shared environment — Tom Moulton <lists@...> 2012/08/07

Ryan Davis wrote in post #1071503:

[#398043] Redefining constants for a given instance only — "Andrea Dallera" <andrea@...>

Hello,=0A=0A=C2=A0 =C2=A0 let's say we have two empty classes:=0A=0Aclass=

9 messages 2012/08/05

[#398063] Join with ActiveRecord using non-standard schema — Tedi Roca <lists@...>

Hi,

13 messages 2012/08/06

[#398135] Help with database-related code pls — Kaye Ng <lists@...>

Hi guys! This is just a part of the code of a program that can load a

12 messages 2012/08/08

[#398190] How do you order your class methods? — masta Blasta <lists@...>

Just getting some layout ideas from other fellow devs.

11 messages 2012/08/10

[#398245] namespace instance methods? — John Doe <lists@...>

I have a large class with many instance methods that I want to

14 messages 2012/08/13

[#398287] Idea: def ... end returns the symbolized version of the newly-defined method, instead of nil — Peter <lumbergh@...>

This would allow useful syntax constructs such as this:

9 messages 2012/08/13

[#398362] case vs if-else — ajay paswan <lists@...>

Which one is faster?

20 messages 2012/08/16

[#398385] A Ruby class is never closed — Rubyist Rohit <lists@...>

Is it true that a Ruby class definition is never closed? Even after

18 messages 2012/08/16

[#398504] How to create an EXecutable file (Linux) — Fosiul Alam <lists@...>

Hi

13 messages 2012/08/22

[#398506] Save a file by clicking on a link — ajay paswan <lists@...>

I clicked a link to download a file using ruby, now I see the open-save

41 messages 2012/08/22

[#398641] force child threads run paralelly? — ajay paswan <lists@...>

I have created two child thread using main thread- child1 and child2.

19 messages 2012/08/28
[#398644] Re: force child threads run paralelly? — ajay paswan <lists@...> 2012/08/28

Ruby version:

[#398648] Re: force child threads run paralelly? — Tony Arcieri <tony.arcieri@...> 2012/08/28

On Tue, Aug 28, 2012 at 7:19 AM, ajay paswan <lists@ruby-forum.com> wrote:

[#398684] Can I do this with Ruby and sqlite alone? — Kaye Ng <lists@...>

Hi guys.

16 messages 2012/08/29

Re: A Ruby class is never closed

From: Robert Klemme <shortcutter@...>
Date: 2012-08-27 21:03:01 UTC
List: ruby-talk #398619
On Mon, Aug 27, 2012 at 10:05 PM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
>
> On Aug 27, 2012, at 02:25 , Robert Klemme <shortcutter@googlemail.com> wrote:
>
>> On Mon, Aug 27, 2012 at 10:58 AM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
>>>
>>> On Aug 27, 2012, at 01:47 , Robert Klemme <shortcutter@googlemail.com> wrote:
>>>
>>>> On Sat, Aug 25, 2012 at 11:36 PM, Marc Heiler <lists@ruby-forum.com> wrote:
>>>>> I think he basically wants to have a class that can never ever again be
>>>>> changed.
>>>>>
>>>>> As far as I know, this is not possible in ruby.
>>>>
>>>> In what ways can you still change a frozen class?
>>>
>>> class X; freeze; end
>>> X = X.dup

Please read again: Marc talked about a class which can never be
changed.  A frozen class is actually such a class AFAIK.  Hence I
asked (Marc) what modifications to a frozen class would be possible (I
could have overlooked something).  So far I haven't seen any.

>> The constant reassignment will prompt a warning.
>
> Oh come one. You know as well as I do how to avoid the warning. That's not the point.
>
>>> class X; def y; end; end # works fine
>>
>> You are not actually modifying the original class X.  Instead you
>> create a copy and modify that.
>
> So what? How is that relevant? The thread is about how to make a locked down system that isn't trivially thwarted. Guess what... it was trivially thwarted.

Well, you may find the point subtle but the class you assign to X the
second time is not the same as the one which was assigned the first
time.  The important bit here is that they do not share identity even
though they can be accessed via the same constant (but at different
times).  This has serious implications especially if there are
instances around of class #1: If you ask them for their class and try
to modify it, the program will fail (unless there are some
modifications possible which I have overlooked - see above).

irb(main):001:0> class X;def f;1 end end
=> nil
irb(main):002:0> o = X.new
=> #<X:0x2027d434>
irb(main):003:0> o.f
=> 1
irb(main):004:0> X.freeze
=> X
irb(main):005:0> X = X.dup
(irb):5: warning: already initialized constant X
=> X
irb(main):006:0> class X; def f;2 end end
=> nil
irb(main):007:0> X.new.f
=> 2
irb(main):008:0> o.f
=> 1
irb(main):009:0> o.class.class_eval { def f; 3 end }
RuntimeError: can't modify frozen Class
        from (irb):9:in `block in irb_binding'
        from (irb):9:in `class_eval'
        from (irb):9
        from /usr/local/bin/irb19:12:in `<main>'
irb(main):010:0> o.f
=> 1
irb(main):011:0> o.class
=> X
irb(main):012:0> o.class.equal? X
=> false

>>> The people looking for these assurances have to be educated that it just isn't something that is worthwhile trying here.
>>
>> Well, at least particular measures help others recognize that it is a
>> bad idea what they are trying (i.e. doing the dup reassign trick you
>> present above can be done but will prompt a warning).
>
> Again. Not the point. You're being (intentionally?) obtuse... It doesn't matter how recognizable it is...

Please spare your ad hominems.

> if the OP wants a locked down system, ruby is NOT the place to attempt it.

Note, that the message which started this thread read:

> Is it true that a Ruby class definition is never closed? Even after
> using the 'end' keyword, the class is available for some dynamic
> operations?

This is not about a "locked down system" but the question whether Ruby
classes can always and under all circumstances be changed.  Freezing
is a way to prevent such change.  So, yes, as long as a class is not
frozen it can be changed almost at will (super class will never
change).  But once it's frozen no modifications are possible that I am
aware of.

Cheers

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

In This Thread