[Soot-list] [McLab] Fwd: Re: Question about McSAF merge
Ismail Badawi
isbadawi at gmail.com
Tue May 7 18:31:36 EDT 2013
I think I see what you mean. It *is* about the caller picking the
implementation class, then, no?
I am not very familiar with Soot, so it's possible we don't have the same
use-cases in mind. I was thinking of the programmer as the analysis-writer,
not the person using the analysis. In McLab at least, the only thing
calling merge() directly is code internal to the analysis framework, which
works only in terms of the generic type parameter A. Someone writes an
analysis and overrides the merge function, but code using the analysis only
works in terms of higher-level methods to access the results. So I was
thinking the only person who cares about the implementation class is the
analysis-writer.
Is this wrong?
Ismail
On Tue, May 7, 2013 at 6:11 PM, Almo <aaloanmiftah at yahoo.com> wrote:
>
> ------------------------------
> *From:* Almo <aaloanmiftah at yahoo.com>
> *To:* Ismail Badawi <isbadawi at gmail.com>
> *Sent:* Tuesday, May 7, 2013 4:10 PM
>
> *Subject:* Re: [McLab] [Soot-list] Fwd: Re: Question about McSAF merge
>
> How would someone using the library change the implementation of <A>
> merge(...) creates for what would be 'out'?
>
> Aaloan
>
> ------------------------------
> *From:* Ismail Badawi <isbadawi at gmail.com>
> *To:* Almo <aaloanmiftah at yahoo.com>
> *Cc:* "soot-list at sable.mcgill.ca" <soot-list at sable.mcgill.ca>; "
> mclab at sable.mcgill.ca" <mclab at sable.mcgill.ca>
> *Sent:* Tuesday, May 7, 2013 4:08 PM
> *Subject:* Re: [McLab] [Soot-list] Fwd: Re: Question about McSAF merge
>
> I am only talking about changing the signature of merge from "void merge(A
> in1, A in2, A out)" to "A merge(A in1, A in2)". How does this change
> preclude the programmer from providing his own implementation class?
>
> Ismail
>
>
> On Tue, May 7, 2013 at 6:04 PM, Almo <aaloanmiftah at yahoo.com> wrote:
>
> Hey,
>
> No, the point is that the programmer has the ability to provide any
> implementation he/she wants to use. As I said, you could avoid this by
> following a factory pattern (where the programmer could supply a factory
> that would generate the implementation they desired). The point is that
> soot is used in many settings, you're never sure what the "general" data
> structure should be (nor should you make that decision for a large library
> yourself anyway). If one person wants to use the standard hash sets, they
> can use those, if another has their own implementation or another that java
> provides, they can use that.
>
> Aaloan
>
> ------------------------------
> *From:* Ismail Badawi <isbadawi at gmail.com>
> *To:* Almo <aaloanmiftah at yahoo.com>
> *Cc:* "soot-list at sable.mcgill.ca" <soot-list at sable.mcgill.ca>; "
> mclab at sable.mcgill.ca" <mclab at sable.mcgill.ca>
> *Sent:* Tuesday, May 7, 2013 4:01 PM
>
> *Subject:* Re: [McLab] [Soot-list] Fwd: Re: Question about McSAF merge
>
> I'm not sure I understand. If A is the return type, you can still return
> any subclass of A. The only difference I can see here is that the code
> calling merge can choose the implementation class of the output
> (ConcurrentSkipListSet here). Is this what you mean?
>
> Ismail
>
>
> On Tue, May 7, 2013 at 5:45 PM, Almo <aaloanmiftah at yahoo.com> wrote:
>
> Forgot to reply all, sorry.
>
> ------------------------------
> *From:* Almo <aaloanmiftah at yahoo.com>
> *To:* Laurie Hendren <hendren at cs.mcgill.ca>
> *Sent:* Tuesday, May 7, 2013 3:44 PM
> *Subject:* Re: [McLab] [Soot-list] Fwd: Re: Question about McSAF merge
>
> Hey,
>
> in1, in2, out
> Can be any an instance of any derived object type of <A>. For example,
>
> void merge(A in1, A in2, A out)
>
> Let's say <A> is java.util.Set, now in1, in2, or out can be any instance
> of a class that implements java.util.Set, so..
>
> in1 = new TreeSet<?>(...);
> in2 = new HashSet<?>(...);
> out = new ConcurrentSkipListSet<?>(...);
> merge(in1, in2, out);
>
> You can avoid this by implementing a factory pattern, but that just
> introduced more complexity than it's worth.
>
> Aaloan
>
> ------------------------------
> *From:* Laurie Hendren <hendren at cs.mcgill.ca>
> *To:* Ismail Badawi <isbadawi at gmail.com>
> *Cc:* Almo <aaloanmiftah at yahoo.com>; Soot-list <soot-list at sable.mcgill.ca>;
> mclab <mclab at sable.mcgill.ca>
> *Sent:* Tuesday, May 7, 2013 3:33 PM
> *Subject:* Re: [McLab] [Soot-list] Fwd: Re: Question about McSAF merge
>
> My question also ...
>
> Laurie
>
> +--------------------------------------------------------------
> | Laurie Hendren --- http://www.sable.mcgill.ca/~hendren
> | Associate Dean (Academic), Faculty of Science
> | Professor, School of Computer Science, McGill University
> | New McLAB project: http://www.sable.mcgill.ca/mclab/
> | Also: www.sable.mcgill.ca/soot www.sable.mcgill.ca/abc
> +--------------------------------------------------------------
>
> On 07/05/2013 5:21 PM, Ismail Badawi wrote:
>
> I don't understand how polymorphism enters into it. Can you explain?
>
> Thanks,
> Ismail
>
>
> On Tue, May 7, 2013 at 4:27 PM, Almo <aaloanmiftah at yahoo.com> wrote:
>
> Hey,
>
> It's because of polymorphism.
>
> Aaloan
>
> ------------------------------
> *From:* Prof. Laurie HENDREN <hendren at cs.mcgill.ca>
> *To:* Soot-list <soot-list at sable.mcgill.ca>; mclab <mclab at sable.mcgill.ca>
>
> *Sent:* Tuesday, May 7, 2013 2:21 PM
> *Subject:* [Soot-list] Fwd: Re: [McLab] Question about McSAF merge
>
> Hi Sooters,
>
> The e-mail thread below questions the API for merge in McSAF. I think
> McSAF inherited the API from Soot, so I would like to know the Soot folks
> take on this. I know we won't want to change Soot now, but McLab is
> new enough that we can still make changes.
>
> Cheers, Laurie
>
>
>
> -------- Original Message -------- Subject: Re: [McLab] Question about
> McSAF merge Date: Tue, 7 May 2013 15:06:37 -0400 From: Matthieu Dubet
> <maattdd at gmail.com> <maattdd at gmail.com> To: Ismail Badawi
> <isbadawi at gmail.com> <isbadawi at gmail.com> CC: mclab
> <mclab at sable.mcgill.ca> <mclab at sable.mcgill.ca>
>
> As you said the only reason I can think of to do that is to avoid the
> allocation in the merge function (
> http://stackoverflow.com/questions/10403766/passing-a-parameter-versus-returning-it-from-function).
>
>
> It is clearly negligeable in 99.9 .. % of the case (especially
> considering the size of flowsets), but it creates a confusion for the user
> ("what is happening to the "out" parameter if it's not an empty set ??? "
> ..etc..) .Â
>
> It is a bad design choice imho.
>
> However, the original author might have been influenced by a wrong C++
> idiom where returning collections as value was considered bad for
> performances so people were passing the output value as input ¶meter.
> But it's not true anyway because of :Â
> * C++11 move semantic
> * automatic return-value-optimization from most compilers before C++11
> * anyway not applicable to Java because of the reference only semantic.
>
>
> On Tue, May 7, 2013 at 2:00 PM, Ismail Badawi <isbadawi at gmail.com> wrote:
>
> Hi,
>
> I was wondering if someone knows why (or can try and justify why) McSAF
> analyses have to implement
>
> void merge(A in1, A in2, A out)
>
> instead of
>
> A merge(A in1, A in2)
>
> The first form is error-prone because you don't know what out is -- e.g.
> if A = Set<String> and you want to do union, it might not be the empty set
> so you should clear it first. But it seems merge is often called with out
> pointing to the same thing as in1 or in2, so you end up having to consider
> a bunch of cases (all three sets the same, all three sets different, in1
> same as out, in2 same as out, etc.) otherwise you risk writing over the
> inputs.
>
> For example, if you wanted to merge sets using union, naively you would
> write
>
> public void merge(Set<String> in1, Set<String> in2, Set<String> out) {
> Â out.clear();
> Â out.addAll(in1);
> Â out.addAll(in2);
> }
>
> but actually you should write
>
> public void merge(Set<String> in1, Set<String> in2, Set<String> out) {
> Â if (in1 != out && in2 != out) {
> Â Â out.clear();
> Â }
> Â if (in1 != out) {
> Â Â out.addAll(in1);
> Â }
> Â if (in2 != out) {
> Â Â out.addAll(in2);
> Â }
> }
>
> which seems needlessly convoluted. I guess I could fix the framework to
> always pass in a newInitialFlow() or something but why not leave it up the
> implementing class? You could write
>
> public Set<String> merge(Set<String> in1, Set<String> in2) {
> Â Set<String> out = new HashSet<String>();
> Â out.addAll(in1);
> Â out.addAll(in2);
> Â return out;
> }
>
> which is more obviously correct.
>
> I guess maybe it's to avoid a memory allocation? But is it worth the
> trouble?
>
> Ismail
>
>
>
>
>
>
> _______________________________________________
> Soot-list mailing list
> Soot-list at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/soot-list
>
>
>
> _______________________________________________
> McLab mailing list
> McLab at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/mclab
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> McLab mailing list
> McLab at sable.mcgill.ca
> http://mailman.cs.mcgill.ca/mailman/listinfo/mclab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.cs.mcgill.ca/pipermail/soot-list/attachments/20130507/9d57142c/attachment-0001.html
More information about the Soot-list
mailing list