1 |
On 03/15/2016 02:19 PM, Brian Dolbec wrote: |
2 |
> On Tue, 15 Mar 2016 14:03:41 -0700 |
3 |
> Zac Medico <zmedico@g.o> wrote: |
4 |
> |
5 |
>> On 03/15/2016 01:57 PM, Brian Dolbec wrote: |
6 |
>>> On Tue, 15 Mar 2016 13:31:24 -0700 |
7 |
>>> Zac Medico <zmedico@g.o> wrote: |
8 |
>>> |
9 |
>>>>> |
10 |
>>>>> Also, now that we are using Fuse, can't we stop returning things |
11 |
>>>>> from these functions entirely, so that dynamic_data is only |
12 |
>>>>> updated by side-effects? |
13 |
>>>>> |
14 |
>>>> |
15 |
>>>> I think 'continue' is the only one left. We could just return a |
16 |
>>>> single boolean, or use an exception to do what 'continue' does. |
17 |
>>> |
18 |
>>> NOPE :( not without a lot more work... |
19 |
>>> |
20 |
>>> arches.py: return {'continue': False, 'arches': arches} |
21 |
>>> depend.py: return {'continue': False, 'unknown_pkgs': unknown_pkgs, |
22 |
>>> 'type_list': type_list, 'badlicsyntax': badlicsyntax, |
23 |
>>> 'baddepsyntax': baddepsyntax} |
24 |
>>> ebuild.py: return {'continue': False, 'ebuild': self} |
25 |
>>> return {'continue': False, 'pkg': self.pkg} |
26 |
>>> isebuild.py: return {'continue': self.continue_, 'pkgs': pkgs, |
27 |
>>> 'can_force': not self.continue_} |
28 |
>>> live.py: return {'continue': False, |
29 |
>>> 'live_ebuild': LIVE_ECLASSES.intersection( |
30 |
>>> kwargs.get('ebuild').inherited)} |
31 |
>>> fetches.py: return {'continue': False, 'src_uri_error': |
32 |
>>> self._src_uri_error} |
33 |
>>> pkgmetadata.py: return {'continue': False, 'muselist': |
34 |
>>> frozenset(self.musedict)} |
35 |
>>> return {'continue': False, 'muselist': |
36 |
>>> frozenset(self.musedict)} |
37 |
>>> scan.py: return {'continue': False, 'eadded': |
38 |
>>> self.vcs_settings.status.eadded} |
39 |
>>> use_flags.py: return {'continue': False, 'ebuild_UsedUseFlags': |
40 |
>>> self.usedUseFlags, 'used_useflags': |
41 |
>>> used_useflags} |
42 |
>>> |
43 |
>>> |
44 |
>>> But we can define a generic dynamic_data class that holds the |
45 |
>>> data that can be modified in a similar way to the Fuse class. That |
46 |
>>> way we don't have to update it like we do a dictionary. |
47 |
>>> |
48 |
>> |
49 |
>> Can't we add all these things to the dynamic_data dict that's |
50 |
>> initialized in Scanner.scan_pkgs (along with Fuse instances), and just |
51 |
>> let them get passed in as arguments, so that the functions can act on |
52 |
>> them without having to return them? |
53 |
> |
54 |
> Yeah, /me is being a dummy. The modules are currently being passed |
55 |
> the dict as a **kwargs. So the individual attributes are accessible |
56 |
> directly. We could just pass it as one arg instead then the modules can |
57 |
> just modify the dictionary directly since it is passed in by pointer. |
58 |
|
59 |
Multiple args work fine too, as long as those args refer to mutable |
60 |
instances that persist outside the function. |
61 |
|
62 |
> Sorry, my head is bouncing back and forth between this and other work |
63 |
> code... But I like how we're getting the code in better shape... |
64 |
> something I had reserved for stage3 ;) |
65 |
|
66 |
I just feel like each step should result in code that is more |
67 |
maintainable than the last, and in the current step we have gone |
68 |
somewhat backwards in maintainability in a specific area. |
69 |
|
70 |
> The current method is the first |
71 |
> thing that came to me when I discovered I needed to get new data back |
72 |
> into the dynamic_data for trailing modules in the queue. |
73 |
|
74 |
You can see how the new approaches we are coming up with are much more |
75 |
maintainable and easier for people to wrap their heads around. |
76 |
-- |
77 |
Thanks, |
78 |
Zac |